Создаётся ощущение, что мода на UML стремительно проходит. Помниться раньше первое, что спрашивали — знаешь ли UML, используешь ли. И после ответа "понимаю, иногда полезно что бы кратко изложить идею на бумаге во время обсуждения" смотрели как на полного отморозка. Сейчас даже особо никто не спрашивает...
Эпиграф: Нет ни одного открытия ни в технологии, ни в методах управления, одно только использование которого обещало бы в течение ближайшего десятилетия на порядок повысить производительность, надежность, простоту разработки программного обеспечения.
Очень часто при чтении работ посвященных ИТ, возникает острое ощущение, что когда-то это уже было, где-то с этим уже встречался, что-то подобное было в прошлом — девавю. Предлагаю обратить внимание на соотношение следующих процитированных ниже материалов.
С одной стороны, развитие ИТ (прежде всего аппаратуры) привело к появлению новых возможностей по реализации более сложных программных систем, нежели ранее, что, разумеется, повлекло, обусловило появление новых способов описания этой самой сложности, с которыми не могли уже справиться старые инструменты описания. Но, с другой стороны, во временном и процентном соотношении: намного ли больше дал нам, к примеру, UML сейчас, нежели раньше давали блок-схемы? Брукс в своей работе (это цитировать не буду, потому как достаточно объемно, да и скорее всего многие уже читали) указывает, что первопричину сложности (т.н. им "сущность") как-либо описать и автоматизировать в обозримом будущем не представляется возможным, есть возможности только по автоматизации акцидентной части разработки (то есть второстепенной, то есть, если очень грубо говоря, реализации с помощью конкретного инструментария уже разработанной/придуманной на первом этапе "сущности"). И блок-схемам он по сути отводит постфактум-роль даже не на этапе разработки "сущности", а именно постфактум-действие этапа реализации! Таким образом, получается, что графическое представление в программировании максимум (то есть дает 100% эффект, практически СП) пригодно только для документирования уже реализованного/готового программного кода. Далее... Есть ведь UML! Последнее время все больше и больше склоняюсь к мнению XP-шников (опять же очень грубая формулировка): если ты не можешь жить без диаграмм — рисуй, если можешь, то забудь о них, ощутимого эффекта (на порядок) ты от них не получишь. Вот и интересно соотношение пользы, которую ранее приносили блок-схемы и полезности UML сейчас.
Часть 1. Итак, примерно 1975 год. Описание действительности, предсказание будущего — по сути нашего настоящего:
Глава 16. Серебряной пули нет — сущность и акциденция в программной инженнерии
Нет ни одного открытия ни в технологии, ни в методах управления, одно только использование которого обещало бы в течение ближайшего десятилетия на порядок повысить производительность, надежность, простоту разработки программного обеспечения.
...
Графическое программирование
Излюбленной темой докторских диссертаций в программной инженерии является графическое, или визуальное, программирование — применение компьютерной графики в разработке программного обеспечения. Иногда перспективы такого подхода основываются на аналогии с проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда такой подход обосновывается, исходя из того, что блок-схемы являются идеальным материалом при проектировании программ. Имеются мощные средства для создания таких блок-схем.
Ничего убедительного и удивительного из этих попыток пока не вышло, — и я уверен, не выйдет.
Во-первых, как я всюду доказываю, блок-схема является весьма слабой абстракцией структуры программы. Лучше всего это видно из попыток Беркса, фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне необходимым управляющим языком высокого уровня. В том жалком виде — многие страницы соединенных линиями прямоугольников, — в котором сегодня разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность: программисты рисуют их после, а не до создания описываемых ими программ. Во-вторых, сегодняшние экраны имеют слишком мало пикселов, чтобы показать целиком и с достаточным разрешением сколько-нибудь подробную схему программы. Так называемая "метафора рабочего стола" становится метафорой "сиденья самолета". Всякий, кому приходилось листать пачку бумаг, будучи стиснутым двумя корпулентными соседями, почувствует разницу: одновременно можно увидеть очень немного. Настоящий рабочий стол позволяет обозревать и произвольно выбирать множество бумаг. Более того, в порыве творчества не один программист или писатель предпочитал рабочему столу более вместительный пол. Аппаратным технологиям нужно сделать очень большой наг, чтобы предоставляемый экранами обзор был достаточным для задач проектирования программ.
Если обратиться к основам, программное обеспечение очень трудно визуализировать, как я доказывал это выше. Составляем ли мы схемы управляющей логики, вложенных областей, видимости переменных, перекрестных ссылок переменных, потоков данных, иерархических структур данных или чего-то еще, они отражают лишь одно изменение взаимодействующих запутанным образом частей программной системы. Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения. Аналогия с интегральными схемами вводит, в сущности, в заблуждение: конструкция микросхемы представляет собой многослойный двумерный объект, геометрия которого отражает сущность. Программная система не является таким объектом.
Часть 2. А теперь, посмотрим, что мы имеем в этом отношении сейчас. Если отмести все различия обусловленные временными рамками, то Фаулер как будто повторяет Брукса:
UML и XP
...
Да, в ХР и UML есть несколько взаимоисключающих аспектов. Так, в ХР существенно снижается значение диаграмм. Не смотря на то, что официальная позиция ХР по этому поводу гласит: "используйте их, если это помогает вам в работе", но существует и неофициальный подтекст: "настоящий ХР-шник не рисует диаграмм". Это подчеркивается еще и тем фактом, что таким людям, как Кент, неудобно использовать диаграммы. Я, например, никогда не видел, чтобы Кент по своей воле рисовал диаграмму программного продукта, неважно даже на языке UML, или каком другом.
Я думаю, что такая ситуация возникает по другим причинам. Во-первых, одни люди считают, что диаграммы полезны, а другие придерживаются противоположного мнения. Фокус в том, что те, которые так считают, полагают, что те, которые так не считают, должны изменить свое мнение, и наоборот. Вместо этого, мы должны просто принять тот факт, что одни люди будут использовать в работе диаграммы, а другие не будут.
Во-вторых, диаграммы программных продуктов обычно ассоциируются с тяжелыми процессами разработки. В таких процессах большая часть времени уходит на построение диаграмм, что не очень помогает в работе, а иногда даже вредит. Именно поэтому я считаю, что людей нужно учить, как использовать диаграммы правильно и избегать различных ловушек, а не просто говорить "рисуй диаграмму, если тебе без нее совсем не обойтись, бедняга", как это обычно делают ярые ХР-шники.
...
Последний пункт стоит раскрыть подробнее. Когда вы занимаетесь предварительным проектированием, вы неизбежно обнаруживаете, что некоторые ваши решения неправильны. Причем обнаруживается это уже при кодировании. Разумеется, это не проблема, если вы после этого вносите соответствующие изменения. Проблемы начинаются тогда, когда вы полагаете, что с проектированием покончено, и не учитываете полученные сведения, сохраняя неверный дизайн.
Изменения в дизайне вовсе необязательно подразумевает изменения в диаграммах. Абсолютно разумным будет просто-напросто выбросить диаграмму, после того, как она помогла вам найти нужное решение. Нарисовав диаграмму, вы решили стоявшую перед вами проблему, и этого совершенно достаточно. Диаграмма и не должна существовать как некий постоянный артефакт. Надо сказать, что лучшие UML-диаграммы такими артефактами как раз не являются.
...
Кроме того, UML-диаграммы используются в качестве документации по проекту. Как правило, в своей обычной форме это модель, редактируемая при помощи некоторого CASE-инструмента. Идея здесь состоит в том, что ведение такой документации облегчает работу. На самом деле, чаще всего она вообще не нужна, поскольку:
нужно постоянно тратить массу времени, чтобы не дать диаграммам устареть, в противном случае, они не будут соответствовать программному коду;
диаграммы находятся внутри сложного CASE-средства либо в толстенной папке, и никто туда не заглядывает.
Итак, если вы хотите иметь текущую документацию по проекту, учитывайте все вышеперечисленные проблемы:Используйте только те диаграммы, которые вы можете поддерживать без особых усилий.
Помещайте диаграммы туда, где их все видят. Я предпочитаю пришпиливать их на стену. Пусть остальные рисуют на ней ручкой все простые изменения, которые были внесены в изначальный вариант.
Посмотрите, обращают ли ваши разработчики на диаграммы хоть какое-то внимание, и если нет, выбросите их.
И, наконец, последний аспект использования UML для документации — передача проекта в другие руки (например, от одной группы разработчиков другой). Согласно методологии ХР, создание документации — такая же задача, как и все остальные, а значит, ее приоритет должен быть определен заказчиком. В этой ситуации может пригодиться UML, разумеется, при условии избирательности диаграмм, которые создавались с целью облегчения коммуникации. Помните, что программный код — это основной репозиторий подробной информации, а диаграммы служат для обобщенного представления основных аспектов системы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, tau797, Вы писали:
T>>>>При том, что многими системами необходимо управлять в реальном масштабе времени. C>>>Оно ортогонально представлению в виде state-машины. T>>Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени. C>Вообще-то, конечный автомат не может представить много чего. Поэтому я и пишу "state-машина" (aka "автомат").
C>>>Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии. T>>Если бы вы потрудились почитать книгу Паронджанова, то наверняка обратили бы внимание на то, что пропагандирует он свой язык T>>не в качестве средства программирования, а как некий универсальный язык для описания алгоритмических аспектов в том числе деятельности T>>человека. C>Вот именно. И я хочу увидеть его приложения в программировании.
C>>>У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов. T>>О вполне реальных проектах я вам писал неоднократно. C>Я не могу их посмотреть.
C>>>Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие. T>>У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например? C>То было давно...
C>>>А вот информатика — в полной заднице. T>>Если не брать производство аппаратных средств, а теорию — то чушь. C>Не чушь. Товарищи из буржуйских стран сейчас занимаются интересными вещами, у нас же практически ничего не происходит.
C>Смотрим: http://arxiv.org/list/cs/pastweek?skip=0&show=25 — сюда сейчас попадают практически все нормальные статьи по информатике.
C>Из русских попались только две статьи: C>http://arxiv.org/pdf/0902.4460 C>http://arxiv.org/abs/0902.4514
C>А вся "Russian Academy of Science" ( http://search.arxiv.org:8081/?query=Russian+Academy+of+Science&in=grp_cs ) проигрывает одному MIT: http://search.arxiv.org:8081/?query=MIT&in=grp_cs со счётом 110 против 3552 (точнее, немного меньше из-за случайных совпадений со словом MIT)!
C>Ещё можно сравнить знаменитый курс MIT'а по программированию и наши курсы в университетах.
C>>>Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится. T>>Я не говорил, что задача — тривиальная. Кстати, при создании вами же упомянутой системы управления парижским метро 14 ветки используется T>>так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки C>Проблема тогда в том, что спека будет аналогом алгоритма. Там всё сложнее — их система позволяет проверять соблюдение инвариантов при создании кода. Оно не полностью автоматическое, и в ряде случаев требует ручного вмешательства.
C>>>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>>Точно, именно так ПО для парижского метро и делали. C>Его делали немного по-другому, однако. Сначала сформировали спеку с набором инвариантов и гарантий, а потом следили за их соблюдением.
T>>>>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского... C>>>Вот это уже интереснее. Но опять, нет видимого результата. T>>Меня утомила ваша "непробиваемость". Полет "Бурана" транслировался по ТВ. Существует множество телепередач и иных материалов, посвященных этому знаменательному событию. "Фрегаты" и "Протоны-М" стартуют с завидной регулярностью. Пуски также демонстрируются по ТВ. Может, со зрением просто проблемы? C>Ты знаешь, я видел стооооооолько софта, который выглядит красиво и даже ещё и работает. Но если посмотреть у него под крышкой — там такой макаронный индусокод, что становится просто страшно.
C>>>сколько там относится к техникам программирования, а сколько к технике организации работ. T>>Технология программирования включает в себя и методы проектирования, и методы документирования, и методы отладки. C>Методы проектирования — нет. Методы документации — частично. Методы отладки — да.
C>>>А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность. T>>"Бизнес-процессы" — поганое модное словечко. Если же рассматривать суть, то "сложность" процессов в бухгалтерии вряд ли сопоставима со сложностью управления в реальном времени десятками взаимодействующих друг с другом и с внешней средой систем. C>Учитывая, что бухгалтерия — это часто как раз те же десятки взаимодействующих друг с другом процессов, которые ещё и часто ведут себя как попало, да ещё всё это и меняется с периодичностью раз в год, да ещё и надо всё это поддерживать за деньги в малую долю разработки ПО типа Шаттловского...
C>Что далеко ходить — система SAP R3 содержит около 250 миллионов строк кода. Т.е. гигабайты исходного кода.
Благодарю за критику, которая была высказана в ходе Вашей дискуссии. Я чрезвычайно ценю подобную критику и приветствую ее. Критика — воздух науки.
Приглашаю всех (кто интересуется языком Дракон и ситуацией вокруг него), на форум "Визуальный язык Дракон", где я принимаю участие в дискуссии программистов и отвечаю на серьезные и острые вопросы. Адрес форума Вам известен: http://forum.oberoncore.ru/viewforum.php?f=62
На Вашем форуме прозвучало критическое замечание, что язык ДРАКОН нельзя использовать для построения сложных программ.
Отвечаю: это не так.
Где используется программное обеспечение языка ДРАКОН?
В Научно-производственный центре автоматики и приборостроения имени академика Н.А.Пилюгина. Здесь реализован на практике и успешно эксплуатируется в течение 12 лет метод «Программирование без прикладных программистов», основанный на использовании языка ДРАКОН.
Созданная технология называется «Технология разработки алгоритмов и программ Графит-Флокс». http://forum.oberoncore.ru/viewtopic.php?f=62&t=1091
Разработка языка ДРАКОН и технологии Графит-Флокс длилась 11 лет (с 1986 по 1996 год). Она используется в следующих крупных ракетно-космических проектах (при разработке систем управления ракет-носителей и разгонных блоков космических аппаратов):
• разгонный блок космических аппаратов ДМ-SL (в рамках международного проекта «Морской старт»);
• разгонный блок космических аппаратов Фрегат;
• модернизированная ракета-носитель тяжелого класса Протон-М;
• разгонный блок космических аппаратов ДМ-03;
• разгонный блок космических аппаратов «Наземный старт» (Старт в пустыне);
• ракета-носитель легкого класса Ангара 1,2;
• ракета-носитель тяжелого класса Ангара-А5;
• и др.
Во всех перечисленных случаях был использован метод «Программирование без прикладных программистов» на основе языка Дракон. Программы на языке ДРАКОН выполняются бортовым компьютером БИСЕР. Этот компьютер создан для установки на борту ракет. Он управляет полетом ракеты, управляет бортовыми системами ракеты и выполняет множество других функций.
Впервые язык Дракон и технология Графит-Флокс были применены на разгонном блоке ДМ-SL (в рамках проекта «Морской старт»).
Первый пуск ракетного комплекса «Морской старт» состоялся 28 марта 1999 г в 5 час. 30 мин. по московскому времени (27 марта 1999 г. в 18 час. 30 мин. по тихоокеанскому времени) с морской стартовой платформы «Одиссей» в Тихом океане на экваторе в районе островов Кирибати.
Чтобы обеспечить этот пуск язык Дракон и технология Графит-Флокс активно использовались на всех этапах разработки системы управления, испытаний и подготовки к пуску в течение трех лет, начиная с 1996 года.
Можно ли использовать язык ДРАКОН при создании программ для обычных персональных компьютеров, ноутбуков, контроллеров и т.д.
Сегодня пока еще нет, нельзя. Для этого надо разработать инструментальные программы ДРАКОНа для персональных компьютеров, ноутбуков и контроллеров.
Такая разработка ведется участниками форума «Визуальный язык дракон» на сайте OberoneCore.ru. Но она еще не закончена.
За рамками ракетно-космической тематики уже сегодня язык ДРАКОН можно использовать для разработки алгоритмов, проектирования программ, создания протоколов взаимодействия и т.д.
Но завтра ситуация изменится. Можно надеяться, что в скором времени язык ДРАКОН получит широкое распространение.
Здравствуйте, serg0s, Вы писали:
C>>Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим. S>А как же с первой частью моего ответа? Посмотрите диаграммы, убедитесь в том, что они таки существуют. А это значит, что Ваше утверждение не имеет оснований.
Это примитив в виде кода они будут выглядеть не хуже.
S>>>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова) C>>Обычно в книгах и не утверждается, что они претендуют на серебряную пулю. S>Обида – не повод для критики. Давайте говорить по существу вопроса.
Где ты видишь обиду?
S>>>Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью. C>>Нет, не направлены. S>Этим только подтверждаете (см. абзац 1 ответа).
Объясняю подробнее: сложность в современных системах обычно НЕ ЛЕЖИТ в коде отдельных методов. Это этап, который проходится программистом за полгода.
Дальше сложность лежит в проектировании системы — разбивке её на модули, организации расширяемости и т.д. Именно это и является сейчас реальным полем исследований. К примеру, книга GoF как раз занимается организацией паттернов проектирования кода — из-за чего и является must read для программиста. Именно по этой причине сейчас появляется интерес к DSL.
А, да. Ещё сейчас широкие массы начинают интересоваться и функциональным программированем — это уже затрагивает и код внутри методов. Жаль только, что автор книги о нём не знает.
Здравствуйте, rsn81, Вы писали:
R>Кто дочитал до этой строчки — герой! R>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
В общем-то согласен. Я еще ни разу не видел, чтобы новомодные MDA и прочие UML-безобразия срабатывали в реальной жизни. Попытки нарисовать программу целиком в Together/Rose обычно заканчиваются полным крахом. Хотя в каких-то узких областях UML может и бывает полезен (мне говорили, что state-диаграммы из UML рулят в телекоме).
В качестве документации для архитектуры UML примерно на уровне обычных квадратиков со стрелочками — но хотя бы тут UML дает хоть какую-то стандартизацию. Но больше всего меня бесят разные "архитекторы", после которых мне достаются длинные портянки со взрывами квадратиков и стрелочек и названиями типа "Use case diagram" или "Actor Model", в которых понять ничерта нельзя. Причем обычно нарисованые совсем не по стандартам UML.
И еще чисто техническая сложность — с большими диаграммами UML сложно работать на экране монитора.
Здравствуйте, Cyberax, Вы писали:
C>"Существенно" — это система в миллион строк кода. Ну или хотя бы в 100000 строк. На таких объёмах уже реально можно оценивать возможности системы. C>К примеру, в ядре Линукса сейчас примерно 9 миллионов строк кода.
Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего? Чтобы она стала никому не нужной? Вы представляете ее объем? Вы вобще видели когда-нибудь такую книгу? Допустим гипотетический случай (хотя на такое пойдет только сумасшедший): автор привел-таки такую диаграмму. Так Вы же первый не станете ее читать. У Вас наверняка найдется другой аргумент.
Короче говоря, Вы требуете от автора, чтобы он стал сумасшедшим. Комментарии как говорится излишни.
Дело не в авторе, повторяю, дело в Вас, в серьезном различии мышления его и Вашего. В силу этого вряд ли Вы сможете понять его плюсы. А минусы есть у всех без исключения, и топтаться на них – дело элементарное. Гораздо сложнее хотя бы попробовать понять.
Опять же повторюсь: не стоит копья ломать на этой теме – толку не будет. Хотя может быть, Вы когда-нибудь признаете право других на мышление, альтернативное Вашему – тогда может еще можно будет поговорить.
C>Я писал десятки (если не больше) протоколов, включая и простую реализацию TCP/IP. В предпоследний раз мне пригодился пакет из Boost'а для реализации state-машины, а в последний раз — поддержка замыканий в языке. На уровне методов ничего сложного там нет — прочитать/записать данные и каким-то образом сменить состояние. C>В документации к протоколу тоже разве что графическая state-диаграмма помогает. десятки (если не больше) протоколов — это явный перебор. Не стоит так подставляться.
Это как раз показывает, что Вы писали не протокол, а уровень приложения для протокола. Там все действительно так как Вы описываете. А это две большие разницы.
C>Вообще-то, никто не говорит про серебряные пули, кроме авторов рекомендуемых книг. DSL — просто ещё один инструментарий для борьбы со сложностью. C>Причём тут сравнение с SQL — мне лично не понятно.
Сравнение с SQL – только в отношении поднятой вокруг средства шумихи. И там и здесь шум гораздо больше результата. Кроме того, это тоже своего рода прикладной язык – для СУБД.
S>>Что касается паттернов и GoF, так это люди просто поделились своим опытом. Когда я читал о паттернах, то почти в половине случаев отмечал, что когда-то это уже было в моей практике, и решено либо схожим образом, либо альтернативным. Вряд ли это следует называть сколь-нибудь существенным шагом вперед – простой обмен опытом, не более. Кстати, у них тоже имеется некоторая доля фетишизации этих самых паттернов. C>GoF — это именно работа по категоризации паттернов, реально используемых программистами, с обсуждением их преимуществ и недостатков. Этим она и полезна. C>Вот подобная рода работа и была бы ценна.
Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более.
C>Именно. Причём не я один — я не знаю ни одного сколь-либо большого проекта (хмм... да даже и сколь-либо малого), разработка которого ведётся с помощью UML.
Я тоже далеко не в восторге от UML. Но скорее всего, по другой причине, уже писал об этом, не буду повторяться. Много было шуму, а результат весьма скромный.
Видите ли, Cyberax, вы упорствуете в своих заблуждениях и ограниченности. T>>А ВЕДЬ ОНА ПРИМЕНЯЕТСЯ, И ДОСТАТОЧНО ДАВНО И УСПЕШНО, ПРИ СОЗДАНИИ ВЕСЬМА СЕРЬЕЗНЫХ И ОТВЕТСТВЕННЫХ ПРОГРАММНЫХ СИСТЕМ — СИСТЕМ УПРАВЛЕНИЯ КОСМИЧЕСКОЙ ТЕХНИКОЙ. C>Я их не видел, и не знаю что там внутри
Тем не менее, находите возможным заявить:
C>почему-то мне кажется, что там ничего технологически сложного нет
Не могу удержаться и не процитировать народную мудрость: "Когда кажется — крестятся".
C>сложность не относится к программированию
Что значит "сложность не относится к программированию"? Кто решает, "к программированию" или нет относится сложность построения системы управления реального времени с высочайшими требованиями к надежности? В данной предметной области приходится иметь дело с весьма сложными системами и ситуациями, требующими синхронизации многих параллельно протекающих процессов с различными вариантами как в логическом, так и временном пространствах. При этом в современных КА задачи эти решаются именно с помощью бортового ПО.
C>Я когда-то лично делал софт управления устройствами. C>Фактически получается просто большая state-машина, где нужно C>аккуратно следить за переходами.
"Большая state-машина" — это, по-Вашему, "просто"?
При этом вы еще оставляете "за скобками" реальное время.
C>Кстати, там действительно были полезными диаграммы состояний.
Ага, все-таки хоть что-то признаете, это уже хорошо.
C>Опять же, немного зная наши НИИ — там могли писать код на том, C>что выгодно защищающему докторскую диссертацию, а не на том, C>что лучше всего бы подошло.
Как вам не стыдно вот так, походя, оскорблять кучу незнакомых вам людей? За которых лучше всего говорят результаты их деятельности? Почитайте там выше — и "Морской старт", и прочее. Да и "Буран" прошу не забывать — для него этими самыми людьми была разработана передовая технология создания высоконадежного бортового ПО, с десятикратным ростом производительности труда!
C>С точки зрения надёжности — как-то графический подход не C>впечатляет
Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему?
C>Например, у НАСА есть система верификации корректности кода, C>которую они используют для части систем ( C>http://javapathfinder.sourceforge.net/ ) C>Для Ады (и С++) есть Coverity и куча других средствЭто хорошо и чудесно, конечно. Однако обратили ли вы внимание на то, что верифицируют эти системы отнюдь не все интересные качества программы, а кроме того — они должна на входе получить готовую программу. А не относятся к этапу проектирования, как ГРАФИТ/ФЛОКС
C>Всё доступно и можно пощупать руками... C>Для "Дракона" же нет _ничего_. Например, на форуме "Дракона"
Не там ищете. Хотя вам русским языком написали о существовании технологии разработки программ, поддержанной соответствующими средствами автоматизации — ГРАФИТ/ФЛОКС. "Пощупать" вы ее не можете по вполне понятным причинам — она применяется на предприятии, занимающемся проектами с очень высокой степенью секретности, в том числе, например, системой управления "Тополей М". Это не значит, что системы нет.
C>Ещё можно вспомнить парижское метро с полностью доказаным C>софтом
Очень сильное заявление. Зуб дадите?
C>Например, на форуме "Дракона" — вообще полный детский сад. C>Простите, но когда редактор всемогущего языка написан (криво) C>на _Дельфи_ — это просто смешно (
Форум — это форум, там, так сказать, народная "инициатива снизу". Кстати, насколько я помню, написано и не на Дельфи
(что вы, между прочим, имеете против дельфи?).
Впрочем, речь не о том. А о ГРАФИТ/ФЛОКС в НПЦ АП — реальной системе на серьезном предприятии, используемой успешно в серьезных проектах — «Морской старт»,«Фрегат»,«Протон-М».
C>что я по-прежнему хочу увидеть хоть один реальный проект. И C>самое прикольное, что я продолжаю быть увереным, что мне C>ничего не покажут
Ну если вы в упор не видите — кто ж вам виноват.
Не уверен, что вы вообще адекватно способны оценить сложность проектов по созданию космической техники. Особенно по сравнению с так называемыми "реальными проектами" в мейнстриме ИТ.
Здравствуйте, Аноним, Вы писали:
А>Только рассуждение будет неполным, если не учитывать некоторые достижения в этих направлениях. Например, по блок-схемам: есть почему-то оставшийся неизвестным широкой публике труд В.Д. Паронджанова «Как улучшить работу ума». При всей претенциозности этого довольно значительного труда, в нем есть несколько совершенно замечательных идей, которые, на мой взгляд, так и не получили должного резонанса в программистском мире.
Просмотрел эту книгу. Кроме изобретения никому нафиг ненужной очередной графической системы "ДРАКОН", у автора какие-то претензии на глобальные идеи суперязыков, развитии мозга и т.п.
А>Главным же относительно обсуждаемого вопроса моментом у Паронджанова является то, что его идеи радикально изменяют место и роль блок-схем в программировании. Он показывает, что можно-таки программировать непосредственно в графике, и это не фантазии автора, а действительно реальное программирование.
Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк.
Простите, но сейчас это совершенно неинтересно. Любой начинающий программист после полугода работы уже просто не оглядывается на детали реализации циклов и операторов ветвлений.
В реальном программировании гораздо более интересны средства борьбы со сложностью большого объёма кода: объектная система, модули, стандартные контейнеры и алгоритмы, система типов, DSL'и и так далее. Что характерно, эти средства позволяют разрабатывать программы размерами в миллионы строк кода.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, tau797, Вы писали:
C>>>сложность не относится к программированию T>>Что значит "сложность не относится к программированию"? C>То и значит. Решение сложного диффура численными методами — это вопрос вычислительной математики. С точки зрения программирования — в большей части вычислительных методов нет ровно никакой сложности
Речь вовсе не шла о вычислительной математике.
C>>>Я когда-то лично делал софт управления устройствами. C>>Фактически получается просто большая state-машина, где нужно аккуратно следить за переходами. T>>"Большая state-машина" — это, по-Вашему, "просто"? T>>При этом вы еще оставляете "за скобками" реальное время. C>Причём оно здесь?
При том, что многими системами необходимо управлять в реальном масштабе времени.
C>Я никогда не отрицал, что в нишевых областях некоторые части UML (и аналогичных им графических методов) бывают полезными. Блин, да я даже в этой теме об этом писал.
Вот и замечательно. Значит, готовы признать свою ошибку, принести извинения и признать полезность ГРАФИТ/ФЛОКСа?
T>>Как вам не стыдно вот так, походя, оскорблять кучу незнакомых вам людей? За которых лучше всего говорят результаты их деятельности? C>Да совсем не стыдно. Я от российских НИИ не вижу пока в моей области ровно ничего нового.
"Я не вижу" и "в моей области" не значит, что этого нет в природе. "Есть многое на свете, друг Горацио..."
Не исключено, кстати, что и в вашей области вы просто недостаточно осведомлены.
C>Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код.
А вы легендами питаетесь? Или фактами?
"Программное обеспечение БЦВК не имеет аналогов среди отечественных систем управления летательных аппаратов как по масштабам и объему разработки, так и по многообразию и сложности решаемых задач... Сложность разработки ПО для ОК состояла в том, что наряду с традиционными для КА задачами управления движением впервые все задачи управления и контроля бортовых систем были реализованы с помощью управляющих программ БЦВК. Значительное число (более 50) бортовых систем и разнородность их задач потребовали различных подходов при реализации управляющих программ. Создание ПО усложнялось большим числом внешних связей как с цифровыми абонентами (БЦВМ сложных систем и приборы, воспринимающие коды БЦВК), так и с получателями релейных команд, с которыми БЦВК общается через дешифраторы. Обеспечение управления движением ОК оказалось весьма трудным делом, что объясняется достаточно сложной динамйческой схемой ОК как объекта управления и принципиально новыми для отечественного и мирового авиа- и ракетостроения задачами: аэродинамическим спуском в плотных слоях атмосферы с гиперзвуковой скоростью, приведением в район ВПП посадочного комплекса и "безмоторной" автоматической посадкой на ВПП. Выполнение этих задач потребовало тесного взаимодействия программ управления движением с программами бортовых систем, причем режимы управления движением, как правило, являются определяющими. Для орбитального управления движением ОК вследствие большого числа нештатных ситуаций характерно многообразие режимов работы с произвольной последовательностью их выполнения. ПО обеспечивает парирование отказов двигателей орбитального маневрирования при выведении, межорбитальных переходах и при сходе с орбиты, ведет учет расхода горючего и окислителя и, при необходимости, регулирование центровки ОК и его номинальной посадочной массы путем слива излишков топлива через тракт двигателей. В случае отказов ракетных блоков I и II ступеней РН СУ ОК обеспечивает в автоматических режимах его аварийное возвращение на ВПП стартового комплекса путем выполнения маневра возврата или выхода на одновитковую траекторию. Высокие требования к точности управления движением обеспечиваются применением усложненных алгоритмов с учетом факторов, которыми ранее пренебрегали. Важной особенностью управления бортовыми системами является программное управление их резервированием. Сложная логика управления избыточностью требует проведения коммутации соответствующих схем и элементов строго по циклограммам управления, поэтому БЦВК не только анализирует числовые значения контрольных величин, но и задает и контролирует временные соотношения в ходе выполнения полетных задач. Алгоритмы управления бортовыми системами проектируются разработчиками систем автоматического управления и передаются программистам для кодирования в системе команд БЦВК. Программы БЦВК отрабатываются автономно на универсальных ЭВМ, где их коды проверяются на соответствие исходным алгоритмам управления. После этапа автономной отработки программы БЦВК проходят комплексные испытания с реальным БЦВК и аппаратурой бортовых систем. Это сложный и наиболее трудоемкий этап разработки ПО, в ходе которого вскрываются не только программные, но и алгоритмические ошибки, вызванные неверным комплексным проектированием или недопониманием сложных аспектов функционирования реальной аппаратуры. При разработке ПО БЦВК достигнуть корректности алгоритмов столь большого комплекса управления было сложно, поэтому для интеграции отдельных программ в единый комплекс ПО потребовалась строгая дисциплина их написания, выдержанная с помощью специализированного языка высокого уровня, что позволило описать не только бортовые алгоритмы управления, но и поведение реальной аппаратуры для моделирования процесса управления на универсальных ЭВМ... Большие информационные потоки, циркулирующие между БЦВК и смежной аппаратурой, заставляют каналы ввода-вывода БЦВМ работать с предельной загрузкой... Для предстартовой подготовки (ПСП) ОК впервые в отечественной практике был применен резервированный вычислительный комплекс на базе общепромышленных ЭВМ, которые позволяют на высоком уровне решать вопросы индикации и документирования ПСП, а их универсальные программные средства — существенно облегчить написание и отладку ее программ, сэкономить время и людские ресурсы. Впервые в отечественной практике на базе трех ЭВМ для осуществления пусковых операций был создан трехканальный синхронный вычислительный комплекс, в котором совместная работа каналов резервирования обеспечивалась специально разработанным аппаратно-программным механизмом, использующим метки начала цикла БЦВК.
Анализ исходных данных для написания программ показал наличие в них большой "информационной загрузки", а опыт предшествующих разработок ПО — неизбежность огромных потерь времени вследствие коррекций в алгоритмах, кабельных связях, адресах абонентов и параметрах признаков. Для автоматизации этого процесса и исключения ручного труда и во избежание внесения дополнительных ошибок была создана информационная система, включающая базу данных с адресами контролируемых параметров и кодовыми конструкциями, принимаемыми или посылаемыми от проверяемой аппаратуры, а также специальный язык описания исходных данных, позволяющий автоматизировать процесс формирования программ на языке универсальной ЭВМ. При таком способе составления программ испытаний при изменениях в электрических схемах или программах БЦВК новые данные вносятся в базу данных информационной системы, которая автоматически определяет новые адреса и кодовые конструкции. Таким образом, коррекция связана лишь с автоматической перетрансляцией программы без изменения текста программы. Такая технология создания ПО позволила в сжатые сроки создать единый бортовой и наземный комплексы ПО общим объемом около 100 Мбайт"
T>>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему? C>Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто.
Дело в значительной степени в традиционной секретности работ, осуществляемых в космической промышленности и ВПК в СССР/России. Впрочем, кое-что я ниже упомянул...
C>>>у НАСА есть система верификации корректности кода, ... есть Coverity и куча других средств T>>Это хорошо и чудесно, конечно. Однако обратили ли вы внимание на то, что верифицируют эти системы отнюдь не все интересные качества программы, а кроме того — они T>должна на входе получить готовую программу. А не относятся к этапу проектирования, как ГРАФИТ/ФЛОКС C>Нельзя доказать корректность того, чего ещё нет.
Можно предложить технологию программирования, которая обеспечит создание корректного ПО.
C>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация.
Вы не правы, хотя рамки сообщения на форуме не позволяют мне подробно осветить здесь этот вопрос.
T>>вам русским языком написали о существовании технологии разработки программ, поддержанной соответствующими средствами автоматизации — ГРАФИТ/ФЛОКС. C>Для меня её всё равно что не существует.
Потрясающий по силе аргумент.
T>>"Пощупать" вы ее не можете по вполне понятным причинам — она применяется на предприятии, занимающемся проектами с очень высокой степенью секретности, в том числе, например, системой управления "Тополей М". Это не значит, что системы нет. C>Странно, вот NASA открыто публикует многие свои инструменты
Как вы думаете, все?
C>Что "сильное"? К примеру, смотри: http://www.bmethod.com/dl/thierry_lecomte/TL_FM2008_Metro_Platform_Screen_Doors_Control_Command_Systems.pdf — и это отчёт не по всему софту, там ещё много чего другого интересного есть.
Спасибо за ссылку, очень интересно! Может, еще чем поделитесь? Особенно интересно по поводу "B-метода".
Вот вам взамен: www.hardline.ru/1/12/1059/
Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского...
C>>>я по-прежнему хочу увидеть хоть один реальный проект. И самое прикольное, что я продолжаю быть увереным, что мне ничего не покажут T>>Ну если вы в упор не видите — кто ж вам виноват. C>Не вижу. Мне нужно всего-то посмотреть исходный код проекта.
Вряд ли вам покажут код системы управления "Тополем"...
C>Сложность в "космических" проектах не лежит в сложности программирования. Она лежит в обеспечении качества и тщательном тестировании.
Вы каким-то странным произвольным образом отделяете "программирование" от обеспечения качества ПО (тут не только тестирование, тут много вопросов, связанных как раз с методами проектирования и верификации иными средствами — в том числе с применением графических средств).
C>Мейнстримовая бухгалтерия запросто может по объёму и сложности технологий превышать космический софт.
Хоть стой, хоть падай. Выше я уже привел данные по причинам сложности ПО "Бурана". Что вы имеете в виду, какие причины "сложности" в бухгалтерских программах??! Там вообще примитивная арифметика и последовательные вычисления.
Здравствуйте, serg0s, Вы писали:
S>Это уже не разговор. Это базар. Чем дальше в лес тем больше дров. Посты все больше а толку уже никакого не осталось.
Его и не было изначально.
S>Я кстати попрощался с Вами еще в прошлом посте. Жаль что Вы этого не поняли. S>Говорю открытым текстом: До свидания.
Да пожалуйста. Таких обиженных тут толпами ходят — кто с Обероном, кто с ТРИЗом. Теперь вот и "Дракон" в этот список добавится.
Здравствуйте, mazurkin, Вы писали:
>> Но говорить, что бухгалтерские программы сложнее программ управления космическими аппаратами некорректно. M>Почему не корректно?
Вы сами ниже отвечаете на свой вопрос. Потому что "сложность" оцениваете лишь в рамках своего понимания (метрики).
Слишком разные по природе объекты. Грубо говоря, "сложность" бухгалтерских программ проистекает от их объема ("план по валу — вал по плану" ). А сложность программ управления КА можно сравнить с принципиально иным качеством проблемы, вызываемым уровнем необходимых интеллектуальных затрат. Примерно как сложность (может, даже правильнее сказать трудность) отрытия огромного котлована соотносится со сложностью постройки радиоприемника.
M>Одной из таких метрик и, пожалуй, самой популярной, явлется количество M>функциональных точек — функции, модуля, всей программы. M>Если у вас есть другая метрика — давайте обсудим.
Если взять, к примеру, "метрику" количества параллельно исполняемых процессов? А число одновременно отсчитываемых таймеров?
Сразу сложность бухгалтерских программ станет околонулевой
M> real-time среда выполнения программы на ее M>сложность никак не влияют, потому как не увеличивают переменные затраты M>на создание ПО
Это, простите, полная глупость.
Здравствуйте, Cyberax, Вы писали:
C>В общем-то согласен. Я еще ни разу не видел, чтобы новомодные MDA и прочие UML-безобразия срабатывали в реальной жизни. Попытки нарисовать программу целиком в Together/Rose обычно заканчиваются полным крахом. Хотя в каких-то узких областях UML может и бывает полезен (мне говорили, что state-диаграммы из UML рулят в телекоме).
Диаграммы состояний рулят во всех случаях, когда состояний не слишком много и они хорошо формализованы. Обычно это что-то достаточно близкое к железу, или просто само железо. Или сервер, откликающийся на пинки клиента — если видов пинков мало, всё это хорошо помещается на экран и действительно помогает понять алгоритм/смысл работы сервера.
C>В качестве документации для архитектуры UML примерно на уровне обычных квадратиков со стрелочками — но хотя бы тут UML дает хоть какую-то стандартизацию. Но больше всего меня бесят разные "архитекторы", после которых мне достаются длинные портянки со взрывами квадратиков и стрелочек и названиями типа "Use case diagram" или "Actor Model", в которых понять ничерта нельзя. Причем обычно нарисованые совсем не по стандартам UML.
use-cases, имхо, вообще лучше текстом писать... На картинке можно только список действующих лиц отразить, а вот содержимое конкретного кейса сложно.
C>И еще чисто техническая сложность — с большими диаграммами UML сложно работать на экране монитора.
Здравствуйте, Cyberax, Вы писали:
S>>Это уже не разговор. Это базар. Чем дальше в лес тем больше дров. Посты все больше а толку уже никакого не осталось. C>Его и не было изначально.
Видите ли, Cyberax, вы прямо-таки погрязли в спеси. Построянно требовать якобы отсутствующего применения графического языка Паронджанова — значит не удосужиться ознакомиться хотя бы с минимумом информации о нем.
А ВЕДЬ ОНА ПРИМЕНЯЕТСЯ, И ДОСТАТОЧНО ДАВНО И УСПЕШНО, ПРИ СОЗДАНИИ ВЕСЬМА СЕРЬЕЗНЫХ И ОТВЕТСТВЕННЫХ ПРОГРАММНЫХ СИСТЕМ — СИСТЕМ УПРАВЛЕНИЯ КОСМИЧЕСКОЙ ТЕХНИКОЙ.
http://ru.science.wikia.com/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D
"К 1998 году все работы по системному программированию были завершены. На базе ДРАКОНА была построена автоматизированная технология проектирования программных систем ( CASE -технология) под рабочим названием «Графит-Флокс»., включающая в себя обширный комплекс программных средств: процедурный редактор, декларативный редактор, базу данных, транслятор, анализатор, кодогенератор и т.д. Автоматизированная Дракон-технология прошла испытания в работе над такими проектами, как : международный космический проект «Морской старт» ( Sea Launch ), российско-французский космический проект «Фрегат», модернизация ракеты-носителя «Протон-М». Поскольку результаты были стабильно высокими, руководство Пилюгинского центра приняло решение использовать дракон-технологию во всех последующих проектах"
Здравствуйте, tau797, Вы писали:
C>>сложность не относится к программированию T>Что значит "сложность не относится к программированию"?
То и значит. Решение сложного диффура численными методами — это вопрос вычислительной математики. С точки зрения программирования — в большей части вычислительных методов нет ровно никакой сложности, хоть на Фортране можно их писать (собственно, чаще всего на нём и пишут).
C>>Я когда-то лично делал софт управления устройствами. C>Фактически получается просто большая state-машина, где нужно C>аккуратно следить за переходами. T>"Большая state-машина" — это, по-Вашему, "просто"? T>При этом вы еще оставляете "за скобками" реальное время.
Причём оно здесь?
C>>Кстати, там действительно были полезными диаграммы состояний. T>Ага, все-таки хоть что-то признаете, это уже хорошо.
Я никогда не отрицал, что в нишевых областях некоторые части UML (и аналогичных им графических методов) бывают полезными. Блин, да я даже в этой теме об этом писал.
C>>Опять же, немного зная наши НИИ — там могли писать код на том, C>что выгодно защищающему докторскую диссертацию, а не на том, C>что лучше всего бы подошло. T>Как вам не стыдно вот так, походя, оскорблять кучу незнакомых вам людей? За которых лучше всего говорят результаты их деятельности?
Да совсем не стыдно. Я от российских НИИ не вижу пока в моей области ровно ничего нового.
T>Почитайте там выше — и "Морской старт", и прочее. Да и "Буран" прошу не забывать — для него этими самыми людьми была разработана передовая технология создания высоконадежного бортового ПО, с десятикратным ростом производительности труда!
Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код.
C>>С точки зрения надёжности — как-то графический подход не C>впечатляет T>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему?
Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто.
C>>Например, у НАСА есть система верификации корректности кода, C>которую они используют для части систем ( C>http://javapathfinder.sourceforge.net/ ) C>>Для Ады (и С++) есть Coverity и куча других средств T>Это хорошо и чудесно, конечно. Однако обратили ли вы внимание на то, что верифицируют эти системы отнюдь не все интересные качества программы, а кроме того — они T>должна на входе получить готовую программу. А не относятся к этапу проектирования, как ГРАФИТ/ФЛОКС
Нельзя доказать корректность того, чего ещё нет. Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация.
C>>Для "Дракона" же нет _ничего_. Например, на форуме "Дракона" T>Не там ищете. Хотя вам русским языком написали о существовании технологии разработки программ, поддержанной соответствующими средствами автоматизации — ГРАФИТ/ФЛОКС.
Для меня её всё равно что не существует.
T>"Пощупать" вы ее не можете по вполне понятным причинам — она применяется на предприятии, занимающемся проектами с очень высокой степенью секретности, в том числе, например, системой управления "Тополей М". Это не значит, что системы нет.
Странно, вот NASA открыто публикует многие свои инструменты, стандарт Ады — открытый и доступный всем.
C>>Ещё можно вспомнить парижское метро с полностью доказаным C>софтом T>Очень сильное заявление. Зуб дадите?
Что "сильное"? К примеру, смотри: http://www.bmethod.com/dl/thierry_lecomte/TL_FM2008_Metro_Platform_Screen_Doors_Control_Command_Systems.pdf — и это отчёт не по всему софту, там ещё много чего другого интересного есть.
C>>Например, на форуме "Дракона" — вообще полный детский сад. C>>Простите, но когда редактор всемогущего языка написан (криво) C>на _Дельфи_ — это просто смешно ( T>Форум — это форум, там, так сказать, народная "инициатива снизу". Кстати, насколько я помню, написано и не на Дельфи T>(что вы, между прочим, имеете против дельфи?).
Написано на Дельфи (я посмотрел). Против Дельфи я ничего не имею, но "Дракон" же в 10 раз увеличивает производительность труда, да? Значит можно было бы переписать редактор "на коленке" за неделю, даже с учётом переписывания всего VCL!
C>>что я по-прежнему хочу увидеть хоть один реальный проект. И C>самое прикольное, что я продолжаю быть увереным, что мне C>ничего не покажут T>Ну если вы в упор не видите — кто ж вам виноват.
Не вижу. Мне нужно всего-то посмотреть исходный код проекта.
T>Не уверен, что вы вообще адекватно способны оценить сложность проектов по созданию космической техники. Особенно по сравнению с так называемыми "реальными проектами" в мейнстриме ИТ.
Сложность в "космических" проектах не лежит в сложности программирования. Она лежит в обеспечении качества и тщательном тестировании.
Мейнстримовая бухгалтерия запросто может по объёму и сложности технологий превышать космический софт.
Здравствуйте, SergH, Вы писали:
SH>use-cases, имхо, вообще лучше текстом писать... На картинке можно только список действующих лиц отразить, а вот содержимое конкретного кейса сложно.
Для формулирования требований к функциональности системы показался более удобным IDEF/0, может быть ошибаюсь, но показалось, что он достигает большей конкретики при том же уровне абстракции, нежели диаграммы вариантов использования.
Интерес к UML значительно поутих после того, как выяснилось, что из неправильных картинок получаются неправильные программы.
А если по-сути, то UML вполне годится как язык диаграмм, но "рисовать все на UML" — экстремальная, а значит, дурная методология.
Рисовать нужно только то, что будет понятнее в виде диаграммы или, если диаграмма хорошо иллюстрирует текст.
А UML в данном случае хорош тем, что более-менее одинаков для всех и все его более-менее знают. Вот и все
Здравствуйте, serg0s, Вы писали:
C>>"Существенно" — это система в миллион строк кода. Ну или хотя бы в 100000 строк. На таких объёмах уже реально S>Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего? Чтобы она стала никому не нужной? Вы представляете ее объем? Вы вобще видели когда-нибудь такую книгу? Допустим гипотетический случай (хотя на такое пойдет только сумасшедший): автор привел-таки такую диаграмму. Так Вы же первый не станете ее читать. У Вас наверняка найдется другой аргумент. S>Короче говоря, Вы требуете от автора, чтобы он стал сумасшедшим. Комментарии как говорится излишни.
Нет, он просит чтобы автор привел пример пример ПОЛЕЗНОЙ системы. Ну не волнует никого, как система реализована на уровне методов.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Cyberax, Вы писали:
S>>Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего? C>Да. Не в тексте книге, а на CD с примерами к ней и/или на сайте автора. Блин, да просто бы любой сторонний проект вполне бы подошёл. C>Другие авторы, однако, умудряются делать подобное. К примеру, код TeX'а у Кнута занимает примерно эти 100000 строк, что подтверждает хотя бы саму возможность "литературного программирования" в проектах длиннее "hello world".
Вы запускали TeX? Кнут из разряда тех же сумасшедших. Только гениальных, которым можно. А поскольку написал библию, то ему все простили. Да и цель у него была на порядок сложнее, чем дракон. Кроме того, тогда был большой разнобой в языках, поскольку очень много народу писало на ассемблерах. И изобретение TeX было вынужденной мерой, только способом выбраться из этой ситуации, не более. Хотел охватить как можно больше народу. Он там прямо так и пишет. Сейчас этого нет, и такие подвиги бессмысленны. И пошел он на это только потому что взялся за глобальную задачу. Так что Вы предлагаете сопоставлять несопоставимое, а значит, подобные аргументы бессмысленны. Все равно что сравнить например, космический корабль и автомобиль. Возьмите пример хотя бы более-менее аналогичный дракону, поскромнее – скажем, Кернигана, Страуструпа или Вирта (хотя и это на мой взгляд несопоставимо). Почувствуйте разницу.
А почему бы Вам не потребовать 100000 строк от GoF? Или они для Вас – вне критики?
C>Я смогу её запустить и посмотреть что получится.
И на чем же Вы хотите ее (диаграмму) запустить? А если не на чем, то опять автор виноват?
Вы это серьезно? По-моему, без юмора относиться к таким заявлениям сложно.
C>Нет. Я не требую ничего необычного.
??? Вы требуете от автора гениальности Кнута – и это называется «ничего необычного»? Так можно и черное назвать белым.
C>Что значит "уровень приложения для протокола"? Я писал именно сам TCP/IP стек (принимающий пакеты напрямую с сетевой карты), сам протокол ARP, когда-то делал минимальный DNS, много раз повторял HTTP-клиенты и серверы и т.д. C>Если считать использованные мной протоколы, то счёт уже на десятки (если не на сотни..) пойдёт.
Уровень приложения – так и называется. В описаниях протоколов есть.
Так все-таки – написанные или использованные? Разница огромная.
C>Ну в общем SQL победил — сейчас это практически единственный используемый язык для работы с данными, и самый распространённый при этом.
Но заявлено было куда бОльшее. Говорилось, что он станет языком для простых юзеров (не программистов). А побеждать было некого – такого класса и для этих целей серьзных языков больше не было. И он занял подобающее ему место, но далеко не то, что ему приписывали.
S>>Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более. C>Он не излагает новое, он предлагает некоторые идеи, которые даже не были опробованы на практике. И я уверен, что и не будут.
Если не новое, то значит, где-то уже было. В таком случае назовите первоисточник.
Здесь Вы ошибаетесь. Опробованы были, и не слабо, и в серьезных разработках. И не только опробованы. Посмотрите на сайте. Да и в книге есть об этом. А уверенность – это опять же из области веры.
Предлагаю этим ограничить дискуссию. Тема исчерпана, количество информации стремится к нулю, а количество слов – растет. И конца этому не видно.
А на мое первое высказывание так и не было адекватного поста (.
Это уже не разговор. Это базар. Чем дальше в лес тем больше дров. Посты все больше а толку уже никакого не осталось.
Я кстати попрощался с Вами еще в прошлом посте. Жаль что Вы этого не поняли.
Говорю открытым текстом: До свидания.
Здравствуйте, tau797, Вы писали:
T>Видите ли, Cyberax, вы прямо-таки погрязли в спеси. Построянно требовать якобы отсутствующего применения графического языка Паронджанова — значит не удосужиться ознакомиться хотя бы с минимумом информации о нем. T>А ВЕДЬ ОНА ПРИМЕНЯЕТСЯ, И ДОСТАТОЧНО ДАВНО И УСПЕШНО, ПРИ СОЗДАНИИ ВЕСЬМА СЕРЬЕЗНЫХ И ОТВЕТСТВЕННЫХ ПРОГРАММНЫХ СИСТЕМ — СИСТЕМ УПРАВЛЕНИЯ КОСМИЧЕСКОЙ ТЕХНИКОЙ.
Я их не видел, и не знаю что там внутри, и почему-то мне кажется, что там ничего технологически сложного нет. Конечно, для управления полётом нужны специальные мат. модели, но их сложность не относится к программированию.
Я когда-то лично делал софт управления устройствами. Фактически получается просто большая state-машина, где нужно аккуратно следить за переходами. Кстати, там действительно были полезными диаграммы состояний. Опять же, немного зная наши НИИ — там могли писать код на том, что выгодно защищающему докторскую диссертацию, а не на том, что лучше всего бы подошло.
С точки зрения надёжности — как-то графический подход не впечатляет. Например, у НАСА есть система верификации корректности кода, которую они используют для части систем ( http://javapathfinder.sourceforge.net/ ). Для Ады (и С++) есть Coverity и куча других средств. Всё доступно и можно пощупать руками. Ещё можно вспомнить парижское метро с полностью доказаным софтом.
Для "Дракона" же нет _ничего_. Например, на форуме "Дракона" — вообще полный детский сад. Простите, но когда редактор всемогущего языка написан (криво) на _Дельфи_ — это просто смешно ( http://forum.oberoncore.ru/viewtopic.php?p=21559#p21559 ). Так что я по-прежнему хочу увидеть хоть один реальный проект. И самое прикольное, что я продолжаю быть увереным, что мне ничего не покажут.
Увы, конструктивного диалога с вами не получилось в силу вашего упорства в заблуждениях и ограниченности мышления C>Здравствуйте, tau797, Вы писали:
T>>>>"Большая state-машина" — это, по-Вашему, "просто"? При этом вы еще оставляете "за скобками" реальное время. C>>>Причём оно здесь? T>>При том, что многими системами необходимо управлять в реальном масштабе времени. C>Оно ортогонально представлению в виде state-машины.
Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени.
T>>Вот и замечательно. Значит, готовы признать свою ошибку, принести извинения и признать полезность ГРАФИТ/ФЛОКСа? C>Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии.
Если бы вы потрудились почитать книгу Паронджанова, то наверняка обратили бы внимание на то, что пропагандирует он свой язык
не в качестве средства программирования, а как некий универсальный язык для описания алгоритмических аспектов в том числе деятельности
человека.
C>У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов.
О вполне реальных проектах я вам писал неоднократно.
T>>Не исключено, кстати, что и в вашей области вы просто недостаточно осведомлены. C>Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие.
У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например?
C>А вот информатика — в полной заднице.
Если не брать производство аппаратных средств, а теорию — то чушь.
C>>>Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код. T>>А вы легендами питаетесь? Или фактами? C>Я знаю лично человека, который писал код для Бурана.
И что? Он с вами подробно делился технологией разработки?
Да и вообще — делать столь далеко идущие выводы на основании единичного наблюдения некорректно.
C>Т.е. они создали что-то типа SCADA с графическим представлением узлов и соединений. Вполне обычная практика, даже я что-то подобное делал.
Попытка принизить чужое выдающееся достижение словами "вполне обычная" вас совсем не красит.
По поводу заявления о "подобном" Вот создали бы вы ПО для "Бурана" — тогда бы и заявляли "я что-то подобное делал".
T>>>>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему? C>>>Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто. T>>Дело в значительной степени в традиционной секретности работ, осуществляемых в космической промышленности и ВПК в СССР/России. Впрочем, кое-что я ниже упомянул... C>Без исходников продираться через дебри невнятных описаний — бессмысленно
Неверный посыл.
C>>>Нельзя доказать корректность того, чего ещё нет. T>>Можно предложить технологию программирования, которая обеспечит создание корректного ПО. C>Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится.
Я не говорил, что задача — тривиальная. Кстати, при создании вами же упомянутой системы управления парижским метро 14 ветки используется
так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки
C>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация.
Точно, именно так ПО для парижского метро и делали.
T>>Вы не правы, хотя рамки сообщения на форуме не позволяют мне подробно осветить здесь этот вопрос. C>Ага. "Cuius rei demonstrationem mirabilem sane detexi. Hanc marginis exiguitas non caperet." (c) Ферма.
Типа того
C>на эту тему тонны литературы написаны.
Ну, спасибо вам большое за конструктивное сотрудничество.
T>>Вот вам взамен: www.hardline.ru/1/12/1059/ T>>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского... C>Вот это уже интереснее. Но опять, нет видимого результата.
Меня утомила ваша "непробиваемость". Полет "Бурана" транслировался по ТВ. Существует множество телепередач и иных материалов, посвященных этому знаменательному событию. "Фрегаты" и "Протоны-М" стартуют с завидной регулярностью. Пуски также демонстрируются по ТВ. Может, со зрением просто проблемы?
Дальше вы уже перешли на хамство, что вынуждает меня отказаться от продолжения дискуссии с вами. Позволю себе напомнить,
что на брудершафт мы, слава Богу, не пили. C>Почитай отчёт о создании софта для Шаттлов. Заметь
C>сколько там относится к техникам программирования, а сколько к технике организации работ.
Технология программирования включает в себя и методы проектирования, и методы документирования, и методы отладки.
C>А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность.
"Бизнес-процессы" — поганое модное словечко. Если же рассматривать суть, то "сложность" процессов в бухгалтерии вряд ли сопоставима со сложностью управления в реальном времени десятками взаимодействующих друг с другом и с внешней средой систем.
Здравствуйте, tau797, Вы писали:
T>>>При том, что многими системами необходимо управлять в реальном масштабе времени. C>>Оно ортогонально представлению в виде state-машины. T>Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени.
Вообще-то, конечный автомат не может представить много чего. Поэтому я и пишу "state-машина" (aka "автомат").
C>>Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии. T>Если бы вы потрудились почитать книгу Паронджанова, то наверняка обратили бы внимание на то, что пропагандирует он свой язык T>не в качестве средства программирования, а как некий универсальный язык для описания алгоритмических аспектов в том числе деятельности T>человека.
Вот именно. И я хочу увидеть его приложения в программировании.
C>>У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов. T>О вполне реальных проектах я вам писал неоднократно.
Я не могу их посмотреть.
C>>Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие. T>У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например?
То было давно...
C>>А вот информатика — в полной заднице. T>Если не брать производство аппаратных средств, а теорию — то чушь.
Не чушь. Товарищи из буржуйских стран сейчас занимаются интересными вещами, у нас же практически ничего не происходит.
Ещё можно сравнить знаменитый курс MIT'а по программированию и наши курсы в университетах.
C>>Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится. T>Я не говорил, что задача — тривиальная. Кстати, при создании вами же упомянутой системы управления парижским метро 14 ветки используется T>так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки
Проблема тогда в том, что спека будет аналогом алгоритма. Там всё сложнее — их система позволяет проверять соблюдение инвариантов при создании кода. Оно не полностью автоматическое, и в ряде случаев требует ручного вмешательства.
C>>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>Точно, именно так ПО для парижского метро и делали.
Его делали немного по-другому, однако. Сначала сформировали спеку с набором инвариантов и гарантий, а потом следили за их соблюдением.
T>>>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского... C>>Вот это уже интереснее. Но опять, нет видимого результата. T>Меня утомила ваша "непробиваемость". Полет "Бурана" транслировался по ТВ. Существует множество телепередач и иных материалов, посвященных этому знаменательному событию. "Фрегаты" и "Протоны-М" стартуют с завидной регулярностью. Пуски также демонстрируются по ТВ. Может, со зрением просто проблемы?
Ты знаешь, я видел стооооооолько софта, который выглядит красиво и даже ещё и работает. Но если посмотреть у него под крышкой — там такой макаронный индусокод, что становится просто страшно.
C>>сколько там относится к техникам программирования, а сколько к технике организации работ. T>Технология программирования включает в себя и методы проектирования, и методы документирования, и методы отладки.
Методы проектирования — нет. Методы документации — частично. Методы отладки — да.
C>>А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность. T>"Бизнес-процессы" — поганое модное словечко. Если же рассматривать суть, то "сложность" процессов в бухгалтерии вряд ли сопоставима со сложностью управления в реальном времени десятками взаимодействующих друг с другом и с внешней средой систем.
Учитывая, что бухгалтерия — это часто как раз те же десятки взаимодействующих друг с другом процессов, которые ещё и часто ведут себя как попало, да ещё всё это и меняется с периодичностью раз в год, да ещё и надо всё это поддерживать за деньги в малую долю разработки ПО типа Шаттловского...
Что далеко ходить — система SAP R3 содержит около 250 миллионов строк кода. Т.е. гигабайты исходного кода.
Здравствуйте, Паронджанов, Вы писали:
П>1. Дракон — это сознательно недоопределенный язык. Далеко не все решения, используемые в космосе, предлагаются для общего пользования.
Сферический дракон в вакууме?
П>5. Поэтому показ реальных кодов может дезориентировать. Чтобы этого не произошло, надо прочесть мою книгу "Как улучшить работу ума" (хотя бы главы 6--17, или хотя бы главы 6--12). П>6. С учетом этих оговорок сообщаю: П>7. Технология разработки алгоритмов и программ ГРАФИТ-ФЛОКС показана здесь П>http://wiki.oberoncore.ru/index.php/%D0%94%D1%80%D0%B0%D0%BA%D0%BE%D0%BD
Опять реклама...
П>9. Силуэт(на псевдокоде) можно посмотреть здесь П>http://forum.oberoncore.ru/viewtopic.php?p=18467#p18467 П>10. Силуэт (код) см. здесь: П>http://forum.oberoncore.ru/viewtopic.php?p=14688#p14688
Вот это уже гораздо более интересно — хоть какой-то реальный код. Но в текстовом виде оно было бы намного проще, особенно если использовать функциональный стиль.
П>11. Крайне желательно научиться пользоваться дракон-редактором Геннадия Тышова. П>12. Буду вам очень благодарен, если Вы сочтете возможным все последующие вопросы задаваь не здесь, а на форуме сайта OberoneCore.ru П>http://forum.oberoncore.ru/viewforum.php?f=62
Нет, мне (да и остальным) удобнее общаться здесь.
Здравствуйте, rsn81, Вы писали:
R>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
Sequence diagrams еще неплохи -- чуть поинформативнее "обычного" call graph'а.
Иногда я еще dataflow рисую, в "интуитивной" нотации (ну, то есть квадратик -- модуль или переменная, в зависимости от уровня детализации, стрелочка -- канал, или процедура выполняющая передачу).
ps. Помнится, когда мне нужно было разрисовать как сложным образом между собой синхронизируются много потоков (там была хитрая конструкция из очередей и пулов потоков, передающая данные из milter'а в собственные треды демона) я пришел к схеме, производной от сетей Петри.
pps. Представляю, как сейчас глумятся "хардкорные UMLщики"
Здравствуйте, Eugene Kilachkoff, Вы писали:
R>>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
EK>Sequence diagrams еще неплохи -- чуть поинформативнее "обычного" call graph'а.
О! Народ! Я знаю — вы знаете! Каким инструментом в Visio (конкретно: 2007-й) sequence diagram-ы рисовать?
А может кто знает какую доку, где подобрано общее описание инструментов и как что удобнее использовать в околософтовых рисунках? Буду страшно благодарен!
Здравствуйте, The Lex, Вы писали: R>>>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
EK>>Sequence diagrams еще неплохи -- чуть поинформативнее "обычного" call graph'а.
TL>О! Народ! Я знаю — вы знаете! Каким инструментом в Visio (конкретно: 2007-й) sequence diagram-ы рисовать?
Конкретно в 2007 не знаю, в 2003 и раньше надо было создать специальный тип диаграммы: UML diagram.
TL>А может кто знает какую доку, где подобрано общее описание инструментов и как что удобнее использовать в околософтовых рисунках? Буду страшно благодарен!
Вот тут народ, например, обсуждает.
Я вот тоже dot/xslt припахивал для анализа кода
Я бы отвел UML скорее техническую документацию нежели конструкторскую, потому что в процессе проектирования изменять электронный вариант просто не получается, только потому что есть бумага или маркерные доски и дифицит времени. При готовом проекте иметь наглядное представление о классах и их взаимодействии и отношении нужнее всего будет, когда придется что-то менять, через некоторое время после окончания проекта. Если говорить по просту, то проще будет вспомнить за чем это так написано и почему это все работает.
Здравствуйте, Vyatsek, Вы писали:
V>Я бы отвел UML скорее техническую документацию нежели конструкторскую, потому что в процессе проектирования изменять электронный вариант просто не получается, только потому что есть бумага или маркерные доски и дифицит времени.
Да, на этапе проектирования и разработки карандаш и тетрадь или доска оказываются удобнее. А для документирования UML хорошо подходит.
Здравствуйте, VGn, Вы писали:
AN>>Да, на этапе проектирования и разработки карандаш и тетрадь или доска оказываются удобнее. А для документирования UML хорошо подходит.
VGn>А что, на доске sequence diagram уже никак не нарисовать?
Документирование это этап, результатом которого будет документация, которая останется для будущих поколений. Так что нарисовать на доске можно, если потом никто стирать не будет или если сфотографировать доску и выложить фотографию в качестве документа (такие случаи я встречал).
Делай что должно, и будь что будет
Re: Дежавю: блок-схемы и UML
От:
Аноним
Дата:
13.02.09 13:47
Оценка:
Здравствуйте, rsn81, Вы писали:
R>Очень часто при чтении работ посвященных ИТ, возникает острое ощущение, что когда-то это уже было, где-то с этим уже встречался, что-то подобное было в прошлом — девавю. Предлагаю обратить внимание на соотношение следующих процитированных ниже материалов.
R>Кто дочитал до этой строчки — герой! R>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
Очень интересная параллель. И место и роль этих средств в общем-то сходны.
Только рассуждение будет неполным, если не учитывать некоторые достижения в этих направлениях. Например, по блок-схемам: есть почему-то оставшийся неизвестным широкой публике труд В.Д. Паронджанова «Как улучшить работу ума». При всей претенциозности этого довольно значительного труда, в нем есть несколько совершенно замечательных идей, которые, на мой взгляд, так и не получили должного резонанса в программистском мире.
Главным же относительно обсуждаемого вопроса моментом у Паронджанова является то, что его идеи радикально изменяют место и роль блок-схем в программировании. Он показывает, что можно-таки программировать непосредственно в графике, и это не фантазии автора, а действительно реальное программирование.
На мой взгляд, беда всех этих средств (блок-схемы, UML) в непродуманности нотации (хотя Паронджанов и в рамках нотации блок-схем умудрился создать нечто значительное — путем установления ограничений), которая не дает возможности работать с насыщенными схемами – сложность восприятия растет быстрее сложности самой схемы. При малых объемах все красиво получается, но столь тривиальные вещи действительно проще сразу программировать – и так все ясно. А при росте объемов сложность составления, восприятия, осмысления схем быстро превышает тот уровень затрат, который программист, разработчик готов потратить на схему.
И вторая часть этой проблемы – практическая полезность схем, диаграмм. Если с ее помощью можно сделать только некоторый «скелет», набросок программного элемента, то совершенно очевидно, что рано или поздно встанет проблема синхронизации схемы с программным кодом. И здесь вопрос в том, что будет легче: либо плюнуть на синхронизацию и продолжать писать, держа при этом в голове всю сложность разрабатываемого элемента, либо делать изменения в схеме, и затем с помощью каких-то средств отражать эти изменения в коде. Этот вопрос является ключевым в использовании графических нотаций. Будет возможность автоматического отображения изменений – тогда эти средства будут востребованы, и могут серьезно изменить технологию программирования. Не будет возможности – и нотация останется языком для аналитиков и преподавателей.
Здравствуйте, Aviator, Вы писали:
A>Создаётся ощущение, что мода на UML стремительно проходит. Помниться раньше первое, что спрашивали — знаешь ли UML, используешь ли. И после ответа "понимаю, иногда полезно что бы кратко изложить идею на бумаге во время обсуждения" смотрели как на полного отморозка. Сейчас даже особо никто не спрашивает...
Вообще по опыту нашего отдела АСУ UML полезно использовать "по-крупному". То есть рисовать примерную архитектуру, структуру БД. Вместо use-case действительно проще словами написать. Диаграммы деятельности — вовсе похожи на блок-схемы. Диаграммы состояний — когда конечные автоматы приходится рисовать — самое то.
А рисовать детально все диаграммы классов и остальные — практически никто не делает.
С точки зрения нашего нормального программера, можно начать с них, потом перейти к коду, а в конце, когда проект уже работает, по работающему проекту уже создать соответствующие диаграммы. Только автоматический инструмент нужно использовать: код -> диаграммы.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Cyberax, Вы писали:
C>Просмотрел эту книгу. Кроме изобретения никому нафиг ненужной очередной графической системы "ДРАКОН", у автора какие-то претензии на глобальные идеи суперязыков, развитии мозга и т.п.
Вобще-то я говорил не о языке, и не о претензиях автора (не спорю, их там хватает). Только давайте оставим их на совести автора и посмотрим, что же в его труде есть полезного. А полезно в нем не столько язык, сколько исследование вопросов, почему графические изображения плохо читаются, и как с этим бороться.
C>Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк.
Есть. Посмотрите диаграммы по ядерному реактору. И структурирование имеется. Кроме того, для книги как раз не следует приводить громоздкие примеры, главное – показать принцип. (Это кстати практически во всех книгах наблюдается – не только у Паронджанова)
C>Простите, но сейчас это совершенно неинтересно. Любой начинающий программист после полугода работы уже просто не оглядывается на детали реализации циклов и операторов ветвлений. C>В реальном программировании гораздо более интересны средства борьбы со сложностью большого объёма кода: объектная система, модули, стандартные контейнеры и алгоритмы, система типов, DSL'и и так далее. Что характерно, эти средства позволяют разрабатывать программы размерами в миллионы строк кода.
Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью. Только не в тексте кода, а в его графическом представлении. Графика способна во многих случаях не то чтобы решать проблему сложности, просто уменьшать ее вредность, и во многих случаях — существенно. И здесь главным образом ценны идеи о том, как сделать графику хорошо читаемой, понятной. На мой взгляд, отсутствием этих качеств страдают все без исключения современные графические языки – и это пожалуй, самый мощный фактор, отталкивающий программистов от графических средств. То есть, дело не в графике как таковой, а в существующих средствах.
Здравствуйте, serg0s, Вы писали:
C>>Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк. S>Есть. Посмотрите диаграммы по ядерному реактору. И структурирование имеется. Кроме того, для книги как раз не следует приводить громоздкие примеры, главное – показать принцип.
Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим.
S>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова)
Обычно в книгах и не утверждается, что они претендуют на серебряную пулю.
C>>В реальном программировании гораздо более интересны средства борьбы со сложностью большого объёма кода: объектная система, модули, стандартные контейнеры и алгоритмы, система типов, DSL'и и так далее. Что характерно, эти средства позволяют разрабатывать программы размерами в миллионы строк кода. S>Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью.
Нет, не направлены.
S>Только не в тексте кода, а в его графическом представлении. Графика способна во многих случаях не то чтобы решать проблему сложности, просто уменьшать ее вредность, и во многих случаях — существенно. И здесь главным образом ценны идеи о том, как сделать графику хорошо читаемой, понятной. На мой взгляд, отсутствием этих качеств страдают все без исключения современные графические языки – и это пожалуй, самый мощный фактор, отталкивающий программистов от графических средств. То есть, дело не в графике как таковой, а в существующих средствах.
Нет.
Здравствуйте, Cyberax, Вы писали:
C>>>Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк. S>>Есть. Посмотрите диаграммы по ядерному реактору. И структурирование имеется. Кроме того, для книги как раз не следует приводить громоздкие примеры, главное – показать принцип. C>Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим.
А как же с первой частью моего ответа? Посмотрите диаграммы, убедитесь в том, что они таки существуют. А это значит, что Ваше утверждение не имеет оснований.
S>>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова) C>Обычно в книгах и не утверждается, что они претендуют на серебряную пулю.
Обида – не повод для критики. Давайте говорить по существу вопроса.
S>>Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью. C>Нет, не направлены.
Этим только подтверждаете (см. абзац 1 ответа).
S>>Только не в тексте кода, а в его графическом представлении. Графика способна во многих случаях не то чтобы решать проблему сложности, просто уменьшать ее вредность, и во многих случаях — существенно. И здесь главным образом ценны идеи о том, как сделать графику хорошо читаемой, понятной. На мой взгляд, отсутствием этих качеств страдают все без исключения современные графические языки – и это пожалуй, самый мощный фактор, отталкивающий программистов от графических средств. То есть, дело не в графике как таковой, а в существующих средствах. C>Нет.
Столь краткие утверждения могут означать либо отсутствие доказательств, или хотя бы суждений, либо нежелание думать над ними. Ваше право. Однако Вы должны понимать, что из-за этого вес их близок к нулю.
Допускаю, что у Вас есть некая внутренняя убежденность в этом. Опять же, имеете право. Но ведь верить можно, например, в господа бога, или в коммунистическую партию. А в программировании, извините, нужны хотя бы мало-мальские доказательства.
Здравствуйте, Cyberax, Вы писали:
C>>>Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим. S>>А как же с первой частью моего ответа? Посмотрите диаграммы, убедитесь в том, что они таки существуют. А это значит, что Ваше утверждение не имеет оснований. C>Это примитив в виде кода они будут выглядеть не хуже.
Но все-таки существенно больше 20 строк
S>>>>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова) C>>>Обычно в книгах и не утверждается, что они претендуют на серебряную пулю. S>>Обида – не повод для критики. Давайте говорить по существу вопроса. C>Где ты видишь обиду?
Обычно таким образом и обижаются. Может, Вы и не обиделись, но выглядит это именно так.
C>Объясняю подробнее: сложность в современных системах обычно НЕ ЛЕЖИТ в коде отдельных методов. Это этап, который проходится программистом за полгода.
Мы с Вами, очевидно, работаем над системами разного рода – соответственно и мнения различаются. Для примера приведу одну из разработок: протокол локальной сети и его программное обеспечение.
Здесь характерна многозначность и многофакторность в алгоритмах, и все это на уровне методов, причем особо не спасает функциональная, да и любая другая декомпозиция – как говорится – хоть вдоль хоть поперек – все едино. Поневоле приходится как-то упрощать представление – в том числе и за счет графики – чтобы справиться именно с логической сложностью. Кстати, есть еще один источник на эту тему, не знаю, известен ли он Вам. Хотел проверить его на каком-нибудь примере, да пока руки не доходят.
C>Дальше сложность лежит в проектировании системы — разбивке её на модули, организации расширяемости и т.д. Именно это и является сейчас реальным полем исследований. К примеру, книга GoF как раз занимается организацией паттернов проектирования кода — из-за чего и является must read для программиста. Именно по этой причине сейчас появляется интерес к DSL.
По поводу DSL. По моему, судьба этого направления будет гораздо печальнее судьбы SQL. А ведь в конце 80х – начале 90х о нем говорили примерно также, как сейчас про DSL. Очередная панацея. Все эти шумихи и моды — для верующих. А начнешь разбираться – и опять дежавю.
Что касается паттернов и GoF, так это люди просто поделились своим опытом. Когда я читал о паттернах, то почти в половине случаев отмечал, что когда-то это уже было в моей практике, и решено либо схожим образом, либо альтернативным. Вряд ли это следует называть сколь-нибудь существенным шагом вперед – простой обмен опытом, не более. Кстати, у них тоже имеется некоторая доля фетишизации этих самых паттернов.
Так что не стоит создавать очередных идолов – их и так хватает в нашем мире.
Очевидно, дело в том, что Ваш ум ориентирован на текстовое представление. Поэтому Вы и не видите особого смысла в графике. Наверное, примерно также Вы относитесь и к UML.
В этом нет ничего ни хорошего ни плохого. Просто есть люди с разным складом ума. Это означает однако, что мы зря с Вами спорим на эту тему: просто потому, что для меня очевидно одно, а для Вас – другое. Для Вас графика не имеет смысла, для меня – наоборот. У каждого свой опыт и свои сложившиеся представления. Так что не стоит копья ломать.
Здравствуйте, serg0s, Вы писали:
C>>Это примитив в виде кода они будут выглядеть не хуже. S>Но все-таки существенно больше 20 строк
"Существенно" — это система в миллион строк кода. Ну или хотя бы в 100000 строк. На таких объёмах уже реально можно оценивать возможности системы.
К примеру, в ядре Линукса сейчас примерно 9 миллионов строк кода.
C>>Объясняю подробнее: сложность в современных системах обычно НЕ ЛЕЖИТ в коде отдельных методов. Это этап, который проходится программистом за полгода. S>Мы с Вами, очевидно, работаем над системами разного рода – соответственно и мнения различаются. Для примера приведу одну из разработок: протокол локальной сети и его программное обеспечение.
Что такое "протокол локальной сети"?
Я писал десятки (если не больше) протоколов, включая и простую реализацию TCP/IP. В предпоследний раз мне пригодился пакет из Boost'а для реализации state-машины, а в последний раз — поддержка замыканий в языке. На уровне методов ничего сложного там нет — прочитать/записать данные и каким-то образом сменить состояние.
В документации к протоколу тоже разве что графическая state-диаграмма помогает.
S>По поводу DSL. По моему, судьба этого направления будет гораздо печальнее судьбы SQL. А ведь в конце 80х – начале 90х о нем говорили примерно также, как сейчас про DSL. Очередная панацея. Все эти шумихи и моды — для верующих. А начнешь разбираться – и опять дежавю.
Вообще-то, никто не говорит про серебряные пули, кроме авторов рекомендуемых книг. DSL — просто ещё один инструментарий для борьбы со сложностью.
Причём тут сравнение с SQL — мне лично не понятно.
S>Что касается паттернов и GoF, так это люди просто поделились своим опытом. Когда я читал о паттернах, то почти в половине случаев отмечал, что когда-то это уже было в моей практике, и решено либо схожим образом, либо альтернативным. Вряд ли это следует называть сколь-нибудь существенным шагом вперед – простой обмен опытом, не более. Кстати, у них тоже имеется некоторая доля фетишизации этих самых паттернов.
GoF — это именно работа по категоризации паттернов, реально используемых программистами, с обсуждением их преимуществ и недостатков. Этим она и полезна.
Вот подобная рода работа и была бы ценна.
S>Очевидно, дело в том, что Ваш ум ориентирован на текстовое представление. Поэтому Вы и не видите особого смысла в графике. Наверное, примерно также Вы относитесь и к UML.
Именно. Причём не я один — я не знаю ни одного сколь-либо большого проекта (хмм... да даже и сколь-либо малого), разработка которого ведётся с помощью UML.
Здравствуйте, serg0s, Вы писали:
C>>К примеру, в ядре Линукса сейчас примерно 9 миллионов строк кода. S>Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего?
Да. Не в тексте книге, а на CD с примерами к ней и/или на сайте автора. Блин, да просто бы любой сторонний проект вполне бы подошёл.
S>Чтобы она стала никому не нужной? Вы представляете ее объем? Вы вобще видели когда-нибудь такую книгу? Допустим гипотетический случай (хотя на такое пойдет только сумасшедший): автор привел-таки такую диаграмму.
Другие авторы, однако, умудряются делать подобное. К примеру, код TeX'а у Кнута занимает примерно эти 100000 строк, что подтверждает хотя бы саму возможность "литературного программирования" в проектах длиннее "hello world".
S>Так Вы же первый не станете ее читать. У Вас наверняка найдется другой аргумент.
Я смогу её запустить и посмотреть что получится.
S>Короче говоря, Вы требуете от автора, чтобы он стал сумасшедшим. Комментарии как говорится излишни.
Нет. Я не требую ничего необычного.
C>>В документации к протоколу тоже разве что графическая state-диаграмма помогает. S>десятки (если не больше) протоколов — это явный перебор. Не стоит так подставляться.
Что удивительного в том, что мне пришлось за долгие годы встретиться с кучей протоколов?
S>Это как раз показывает, что Вы писали не протокол, а уровень приложения для протокола. Там все действительно так как Вы описываете. А это две большие разницы.
Что значит "уровень приложения для протокола"? Я писал именно сам TCP/IP стек (принимающий пакеты напрямую с сетевой карты), сам протокол ARP, когда-то делал минимальный DNS, много раз повторял HTTP-клиенты и серверы и т.д.
Если считать использованные мной протоколы, то счёт уже на десятки (если не на сотни..) пойдёт.
C>>Причём тут сравнение с SQL — мне лично не понятно. S>Сравнение с SQL – только в отношении поднятой вокруг средства шумихи. И там и здесь шум гораздо больше результата. Кроме того, это тоже своего рода прикладной язык – для СУБД.
Ну в общем SQL победил — сейчас это практически единственный используемый язык для работы с данными, и самый распространённый при этом.
C>>GoF — это именно работа по категоризации паттернов, реально используемых программистами, с обсуждением их преимуществ и недостатков. Этим она и полезна. C>>Вот подобная рода работа и была бы ценна. S>Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более.
Он не излагает новое, он предлагает некоторые идеи, которые даже не были опробованы на практике. И я уверен, что и не будут.
Приветствую еще одного участника нашего затянувшегося спора .
AJD>Нет, он просит чтобы автор привел пример пример ПОЛЕЗНОЙ системы.
Видите ли, в нашем с Cyberax диалоге нет ни одного слова о полезности применительно к книге. Допускаю, что Cyberax подразумевал это, но согласитесь, трудно понять то, что не говорится, а подразумевается.
А система управления ядерным реактором – не полезная? Мне кажется, Вы несколько не тот акцент хотели высказать.
Возможно, речь идет о полезности для читателя. Так ведь Вы и Cyberax не единственные читатели. Ну не нашли ничего для себя – так я тоже в подавляющем большинстве книг для себя ничего не нахожу. Это не повод для критики. Если книга для меня бесполезна, я просто ее не беру. Но это не значит, что она для других не полезна. Люди все разные, каждому нужно свое. А книга Паронджанова нашла своего читателя – кто-то даже компилятор сделал для дракона.
Хотя, повторяю, есть у него и минусы, и немало – но в другом.
AJD> Ну не волнует никого, как система реализована на уровне методов.
Дело в том, что язык дракон построен на базе граф-схем алгоритмов (по ГОСТ). А они предназначены для представления алгоритмов, то есть для уровня, соответствующего методам. Если Вас волнует что-то другое – так это же не повод для дискуссии о драконе. Меня тоже далеко не только это волнует. И системные вопросы очень интересуют. Готов на эти темы разговаривать, и уже говорю. Например, в этом топике. Только мы здесь говорим о книге Паронджанова и его драконе. Хотя уже очень сильно отклонились . И похоже, спор грозит стать бесконечным .
Здравствуйте, serg0s, Вы писали:
C>>Другие авторы, однако, умудряются делать подобное. К примеру, код TeX'а у Кнута занимает примерно эти 100000 строк, что подтверждает хотя бы саму возможность "литературного программирования" в проектах длиннее "hello world". S>Вы запускали TeX?
Я им пользуюсь.
S>Кнут из разряда тех же сумасшедших. Только гениальных, которым можно. А поскольку написал библию, то ему все простили. Да и цель у него была на порядок сложнее, чем дракон. Кроме того, тогда был большой разнобой в языках, поскольку очень много народу писало на ассемблерах. И изобретение TeX было вынужденной мерой, только способом выбраться из этой ситуации, не более.
Опять мимо. TeX написан на Паскале (точнее, на C-WEB), и прежде всего является практической утиллитой — он документы форматирует.
S>Хотел охватить как можно больше народу. Он там прямо так и пишет. Сейчас этого нет, и такие подвиги бессмысленны. И пошел он на это только потому что взялся за глобальную задачу. Так что Вы предлагаете сопоставлять несопоставимое, а значит, подобные аргументы бессмысленны. Все равно что сравнить например, космический корабль и автомобиль. Возьмите пример хотя бы более-менее аналогичный дракону, поскромнее – скажем, Кернигана, Страуструпа или Вирта (хотя и это на мой взгляд несопоставимо). Почувствуйте разницу.
Керниган помогал писать первый Юникс на С, Страуструп писал на С++ компилятор С++, Вирт создал несколько компиляторов. У них у всех был практический опыт применения их языков.
Единственный чистый академик в современной информатике, которого я знаю, — это Дийкстра.
S>А почему бы Вам не потребовать 100000 строк от GoF? Или они для Вас – вне критики?
Авторы GoF систематизировали уже существующие знания, в том числе и по проектам гораздо большего размера. Так что к ним претензий нет.
C>>Я смогу её запустить и посмотреть что получится. S>И на чем же Вы хотите ее (диаграмму) запустить?
На компьютере. И не надо отмазываться сложностью реализации. Интепретаторы (да даже и компиляторы) языков при использовании современных инструментальных средств делается даже второкурсниками в качестве курсовых.
S>А если не на чем, то опять автор виноват?
Да.
S>Вы это серьезно? По-моему, без юмора относиться к таким заявлениям сложно.
Если это так, то книгам автора — в помойку.
C>>Нет. Я не требую ничего необычного. S>??? Вы требуете от автора гениальности Кнута – и это называется «ничего необычного»? Так можно и черное назвать белым.
Нет. Я не требую труда уровня Кнута. Я просто требую КАКУЮ-НИБУДЬ ПРАКТИЧЕСКУЮ РЕАЛИЗАЦИЮ его идей!!
C>>Если считать использованные мной протоколы, то счёт уже на десятки (если не на сотни..) пойдёт. S>Уровень приложения – так и называется. В описаниях протоколов есть.
Ссылку, на спеки, пожалуйста. Я знаю термин "уровень приложения" в модели OSI, но причём он тут — мне не понятно.
S>Так все-таки – написанные или использованные? Разница огромная.
Написанные, написанные.
C>>Ну в общем SQL победил — сейчас это практически единственный используемый язык для работы с данными, и самый распространённый при этом. S>Но заявлено было куда бОльшее. Говорилось, что он станет языком для простых юзеров (не программистов). А побеждать было некого – такого класса и для этих целей серьзных языков больше не было. И он занял подобающее ему место, но далеко не то, что ему приписывали.
Он используется и простыми пользователями. Причём даже там где и надо — в аналитике.
S>>>Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более. C>>Он не излагает новое, он предлагает некоторые идеи, которые даже не были опробованы на практике. И я уверен, что и не будут. S>Если не новое, то значит, где-то уже было. В таком случае назовите первоисточник.
Графического программирования? Это ещё в "Mythical Man-Month" про схемы было написано. Вообще, систем графического программирования было полно. Ни одна не прижилась.
S>Здесь Вы ошибаетесь. Опробованы были, и не слабо, и в серьезных разработках. И не только опробованы. Посмотрите на сайте. Да и в книге есть об этом. А уверенность – это опять же из области веры.
Ну покажите мне эти "разработки" — ткните носом. Чтоб я мог скачать и посмотреть как оно там всё круто работает.
Здравствуйте, tau797, Вы писали:
T>>>"Большая state-машина" — это, по-Вашему, "просто"? T>>>При этом вы еще оставляете "за скобками" реальное время. C>>Причём оно здесь? T>При том, что многими системами необходимо управлять в реальном масштабе времени.
Оно ортогонально представлению в виде state-машины.
C>>Я никогда не отрицал, что в нишевых областях некоторые части UML (и аналогичных им графических методов) бывают полезными. Блин, да я даже в этой теме об этом писал. T>Вот и замечательно. Значит, готовы признать свою ошибку, принести извинения и признать полезность ГРАФИТ/ФЛОКСа?
Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии.
У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов.
C>>Да совсем не стыдно. Я от российских НИИ не вижу пока в моей области ровно ничего нового. T>"Я не вижу" и "в моей области" не значит, что этого нет в природе. "Есть многое на свете, друг Горацио..." T>Не исключено, кстати, что и в вашей области вы просто недостаточно осведомлены.
Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие.
А вот информатика — в полной заднице.
C>>Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код. T>А вы легендами питаетесь? Или фактами?
Я знаю лично человека, который писал код для Бурана.
T>При таком способе составления программ испытаний при изменениях в электрических схемах или программах БЦВК новые данные вносятся в базу данных информационной системы, которая автоматически определяет новые адреса и кодовые конструкции. Таким образом, коррекция связана лишь с автоматической перетрансляцией программы без изменения текста программы. Такая технология создания ПО позволила в сжатые сроки создать единый бортовой и наземный комплексы ПО общим объемом около 100 Мбайт"
Т.е. они создали что-то типа SCADA с графическим представлением узлов и соединений. Вполне обычная практика, даже я что-то подобное делал.
Я всё же хочу увидеть применение ДРАКОНа в качестве языка программирования общего пользования.
T>>>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему? C>>Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто. T>Дело в значительной степени в традиционной секретности работ, осуществляемых в космической промышленности и ВПК в СССР/России. Впрочем, кое-что я ниже упомянул...
Без исходников продираться через дебри невнятных описаний — бессмысленно.
C>>Нельзя доказать корректность того, чего ещё нет. T>Можно предложить технологию программирования, которая обеспечит создание корректного ПО.
Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится.
C>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>Вы не правы, хотя рамки сообщения на форуме не позволяют мне подробно осветить здесь этот вопрос.
Ага. "Cuius rei demonstrationem mirabilem sane detexi. Hanc marginis exiguitas non caperet." (c) Ферма.
C>>Странно, вот NASA открыто публикует многие свои инструменты T>Как вы думаете, все?
Достаточно заметную часть.
C>>Что "сильное"? К примеру, смотри: http://www.bmethod.com/dl/thierry_lecomte/TL_FM2008_Metro_Platform_Screen_Doors_Control_Command_Systems.pdf — и это отчёт не по всему софту, там ещё много чего другого интересного есть. T>Спасибо за ссылку, очень интересно! Может, еще чем поделитесь? Особенно интересно по поводу "B-метода".
Это применение работ по доказательству кода, на эту тему тонны литературы написаны.
T>Вот вам взамен: www.hardline.ru/1/12/1059/ T>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского...
Вот это уже интереснее. Но опять, нет видимого результата.
T>>>Ну если вы в упор не видите — кто ж вам виноват. C>>Не вижу. Мне нужно всего-то посмотреть исходный код проекта. T>Вряд ли вам покажут код системы управления "Тополем"...
Так почему нет ничего другого-то??
C>>Сложность в "космических" проектах не лежит в сложности программирования. Она лежит в обеспечении качества и тщательном тестировании. T>Вы каким-то странным произвольным образом отделяете "программирование" от обеспечения качества ПО (тут не только тестирование, тут много вопросов, связанных как раз с методами проектирования и верификации иными средствами — в том числе с применением графических средств).
Почитай отчёт о создании софта для Шаттлов. Заметь сколько там относится к техникам программирования, а сколько к технике организации работ.
Это близкие области, но далеко не одно и то же.
C>>Мейнстримовая бухгалтерия запросто может по объёму и сложности технологий превышать космический софт. T>Хоть стой, хоть падай. Выше я уже привел данные по причинам сложности ПО "Бурана". Что вы имеете в виду, какие причины "сложности" в бухгалтерских программах??!
Обыкновенные.
T>Там вообще примитивная арифметика и последовательные вычисления.
А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность.
Здравствуйте, Паронджанов, Вы писали:
П>За рамками ракетно-космической тематики уже сегодня язык ДРАКОН можно использовать для разработки алгоритмов, проектирования программ, создания протоколов взаимодействия и т.д. П>Но завтра ситуация изменится. Можно надеяться, что в скором времени язык ДРАКОН получит широкое распространение.
Неужели совсем никак нельзя показать реальные примеры применения ДРАКОНа, чтобы можно было посмотреть на реальный вид программ на нём?
А>На мой взгляд, беда всех этих средств (блок-схемы, UML) в непродуманности нотации (хотя Паронджанов и в рамках нотации блок-схем умудрился создать нечто значительное — путем установления ограничений), которая не дает возможности работать с насыщенными схемами – сложность восприятия растет быстрее сложности самой схемы.
Ошибка подхода.
Представление системы слищком плоское, потому что не продумана архитектура, а не из-за особенностей UML.
А>И вторая часть этой проблемы – практическая полезность схем, диаграмм. Если с ее помощью можно сделать только некоторый «скелет», набросок программного элемента, то совершенно очевидно, что рано или поздно встанет проблема синхронизации схемы с программным кодом. И здесь вопрос в том, что будет легче: либо плюнуть на синхронизацию и продолжать писать, держа при этом в голове всю сложность разрабатываемого элемента, либо делать изменения в схеме, и затем с помощью каких-то средств отражать эти изменения в коде.
Ошибка подхода.
При правильной декомпозиции схемы зарагивают по большей части архитектуру и ключевой функционал, которые меняться должны как можно реже.
Рисовать вообще всю систему целиком — это идиотизм.
"Неужели совсем никак нельзя показать реальные примеры применения ДРАКОНа, чтобы можно было посмотреть на реальный вид программ на нём?"
Я понимаю ситуацию так. Вы очень опытный и очень занятый специалист. Вы хотите затратить минимум времени: взглянуть на код и составить собственное мнение. Я с уважением отношусь к вашему желанию.
Но здесь есть трудности.
1. Дракон — это сознательно недоопределенный язык. Далеко не все решения, используемые в космосе, предлагаются для общего пользования.
2. Я предлагаю ТОЛЬКО маршрутную часть языка (то есть слепыш дракон-схемы). Все осталное (заполнение слепыша текстом и декларативную часть (описание данных и классов) не входит в состав моего предложения. Их надо делать заново. (Наши космические решения здесь вряд ли могут претендовать на что-то).
3. Я использую существенно другую математику. Решения, предложенные Дейкстрой и Хоаром, подвергаются значительной модификации и развитию.
4. И так далее.
5. Поэтому показ реальных кодов может дезориентировать. Чтобы этого не произошло, надо прочесть мою книгу "Как улучшить работу ума" (хотя бы главы 6--17, или хотя бы главы 6--12).
8. Прочитайте также Извлечение из документа "Язык ФЛОКС". (Там же). Но там Вы увидите коды примитива, а рекомендуемой конструкцией является не примитив, а СИЛУЭТ.
Паронджанов пишет: > > показ реальных кодов может дезориентировать. Чтобы этого не > произошло, надо прочесть мою книгу "Как улучшить работу ума"
Респект. Под столом )
--
WBR,
Serge.
Автору — извините, я далёк от обсуждаемой темы и сказанное никак не
относится к достоинствам и недостаткам предлагаемого. Просто фраза очень
понравилась.
hrensgory wrote:
> Автору — извините, я далёк от обсуждаемой темы и сказанное никак не > относится к достоинствам и недостаткам предлагаемого. Просто фраза очень > понравилась.
А еще совершенно необходимо овладеть навыками работы на дешкомпьютере!
Не для Cybera, а истины для и остальных, кто сюда заглянет.
T>>Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени. C>Вообще-то, конечный автомат не может представить много чего. Поэтому я и пишу "state-машина" (aka "автомат").
У меня слова "конечный" не было. Впрочем, бесконечный нетаймированный автомат тоже представить адекватно систему реального времени не может, конечно.
T>>У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например? C>То было давно...
Было, есть в настоящее время, и будет. http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%81%D1%8C%D1%8F%D0%BD%D0%BE%D0%B2,_%D0%92%D0%B8%D0%BA%D1%82%D0%BE%D1%80_%D0%9D%D0%B8%D0%BA%D0%BE%D0%BB%D0%B0%D0%B5%D0%B2%D0%B8%D1%87
C>Не чушь. Товарищи из буржуйских стран сейчас занимаются интересными вещами, у нас же практически ничего не происходит.
Если кое-кому о чем-то неизвестно, вынужден повториться, это не значит, что это отсутствует в природе. http://www.iis.nsk.su/preprints/abstracts_ru.shtml http://www.iis.nsk.su/projects/index.shtml http://www.iis.nsk.su/preprints/books/index_ru.shtml http://www.spiiras.nw.ru/modules.php?name=Content&pa=showpage&pid=16 http://www.ccas.ru/ http://space.iias.spb.su/ http://www.keldysh.ru/projects/projects-fr.html http://library.keldysh.ru/prep_ls.asp
C>Смотрим: http://arxiv.org/list/cs/pastweek?skip=0&show=25 — сюда сейчас попадают практически все нормальные статьи по информатике. Вот прямо все.
C>А вся "Russian Academy of Science" ( http://search.arxiv.org:8081/?query=Russian+Academy+of+Science&in=grp_cs ) проигрывает одному MIT: http://search.arxiv.org:8081/?query=MIT&in=grp_cs со счётом 110 против 3552 (точнее, немного меньше из-за случайных совпадений со словом MIT)!
Конечно, следует приветстовать, если человек интересуется, что происходит в его проблемной области в мире. В то же время низкопоклонство перед Западом приветствовать вряд ли стоит.
C>Ещё можно сравнить знаменитый курс MIT'а по программированию и наши курсы в университетах.
Можно сравнить. Не так плохи курсы во многих наших университетах, и не только в Москве и Санкт-Петербурге.
T>>при создании вами же упомянутой системы управления парижским метро 14 ветки используется T>>так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки C>Проблема тогда в том, что спека будет аналогом алгоритма. Там всё сложнее — их система позволяет проверять соблюдение инвариантов при создании кода. C>>>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>>Точно, именно так ПО для парижского метро и делали. C>Его делали немного по-другому, однако. Сначала сформировали спеку с набором инвариантов и гарантий, а потом следили за их соблюдением.
Все именно так, как я написал. Да, "спецификация" на B-языке по объему приблизительно соответствует записи программы на "обычном" языке программирования. Да, при этом она снабжается описанием инвариантов.
C>Что далеко ходить — система SAP R3 содержит около 250 миллионов строк кода. Т.е. гигабайты исходного кода. C>бухгалтерия — это часто как раз те же десятки взаимодействующих друг с другом процессов
Он не взаимодействуют в реальном времени, конечно же. И "бухгалтерские" программы по сути своей безнадежно последовательны. Вычислительной сложности в них тоже нет. Сложность там возникает в связи с объемами, это да.
Но говорить, что бухгалтерские программы сложнее программ управления космическими аппаратами некорректно.
> Но говорить, что бухгалтерские программы сложнее программ управления космическими аппаратами некорректно.
Почему не корректно?
Чтобы что-то с чем-то сравнивать нужно определить методику и привести
обе стороны к сравнимому виду. В области инженерии ПО такие методики
существуют уже давно, как и численные метрики измерения различных
характиристик создаваемого ПО, в том числе и его сложности.
Одной из таких метрик и, пожалуй, самой популярной, явлется количество
функциональных точек — функции, модуля, всей программы. Существуют
утилиты для измерения этой метрики для многих языков программирования.
В свете этой метрики ни супер-хитрые формулы учитывающие гравитацию всех
планет солнечной системы, ни real-time среда выполнения программы на ее
сложность никак не влияют, потому как не увеличивают переменные затраты
на создание ПО, а лишь являются технологическими аспектами (а формулы и
тест-данные их верификации вообще составляют обязательную часть ТЗ).
. Сейчас даже особо никто не спрашивает...
Зуб дадите?
— кто ж вам виноват.
Вот создали бы вы ПО для "Бурана" — тогда бы и заявляли "я что-то подобное делал".
. И похоже, спор грозит стать бесконечным 
