Согласен - это дополнительная форма представления, только прежде всего не алгоритма, а системы алгоритмов - чтобы можно было её "охватить одним взглядом" (симультанно). Только для этого нужна возможность свёртки линейных участков, о чём говорил выше.
В перспективе некоторые детали надо переделать, улучшить, но в основном постановка и интерфейс стабилизировались.
... Нет привязки к конкретному языку программирования и предусматривает внимание на алгоритме в проблемной области.
В ваших ссылках использованы конкретные языки программирования с изменением формы записи.
К вопросу о трансляции. Среда Drakon предлагает хранение программных текстов в полях алгоритма и формирование шаблона текста программного кода модуля...
Становится необходимым снова взглянуть на контекст, в котором принимаются решения, подобные обсуждаемому в этой теме. Можно было бы ограничиться сказанным
в этом сообщении и
на этой странице - но некоторые обстоятельства обусловливают необходимость высказаться "резче и грубее", как говорит Владимир Даниелович
Так, только недавно
в сообщении о роли ГНОМа говорил об необходимости внедрения эргономичных решений в практику, тем более в критических отраслях - и вот:
С языком ДРАКОН и и.с. DRAKON познакомил программистов (одного из ведущих) Севмашпредприятия. Заинтересовались и попросили разрешение выложить материалы в свободном доступе во внутризаводском интернете. Дал согласие, об использовании на сегодня ничего не знаю.
Само по себе предложение ко внедрению конкретной реализации правильно и своевременно - пора уже выходить в практику. Интересен был бы опыт внедрения - но оборонная сфера такова, что даже изложенный обезличенно в отношении разрабатываемых объектов, он может содержать элементы охраняемых сведений - и потому мы не вправе в общем случае просить об ознакомлении. Ну а в частности - захотят представители такого рода организации в установленном порядке сформировать через соответствующие службы сообщение о результатах и представить его в т.ч. на данную конференцию - скажем им за это спасибо
Лишний раз стоит поблагодарить и Геннадия Николаевича - никто ведь его не заставляет заниматься развитием Ты-среды и не стимулирует
Вместе с тем потенциальная возможность использования именно в такой сфере данной реализации - и фактически установленного ею стандарта на семейство языков визуализации и на технологию автоматизированного описания задач - вызывает серьёзные вопросы.
Что практически даст внедрение указанной реализации техноязыка? Свойствами Ты-среды как инфопрогизделия можно для начала пренебречь - хотя по
теме "Тестирование и.с. Drakon" ясно, что это продукт поисковый, не промышленный. Но и свойства языкового базиса, как он определён Геннадием Николаевичем (ДРАКОН+ГНОМ+Дамке-схемы), не позволяют считать его вполне эргономичным средством представления знаний.
Здесь уже говорилось (Ильёй Евгеньевичем, Фёдором Васильевичем) о том, что механизмы языка д.б. обоснованы требованиями к качеству разрабатываемой на нём системы. В этом смысле исходный техноязык неполон - к алгоритмам всё не сводится. В Ты-среде по-своему он восполняется - но как? Дамке-деревья с возвратами нарушают целостность восприятия, требуя обратного следования по цепям. Про роль ГНОМа уже сказал достаточно в упомянутом сообщении. Деклар-языка визуального как не было, так и нет. И вспомогательных элементов визуализации (КогниСтиль и пр.) тоже. Если принимать за основу разработки не то, что саму Ты-среду - но просто её концептуальные решения - говорить об "улучшении работы ума" над задачами в такой среде не считаю возможным - как бы не было ухудшения по сравнению с тем же Блэкбоксом...
Вспоминается такой эпизод. Как-то на учебной практике присутствовал при работе разработчика программно-аппаратных устройств с заказчиком в роли "ученика аналитика". В детали не вникал - извлекал для себя именно суть процесса взаимодействия. А получалось вот что - представители заказчика в погонах вплоть до беспросветных пытались разобраться, почему же это образец устройства не делает того, что положено по техзаданию. И не получалось у них взаимопонимания - заказчик о несоответствии показателям, а разработчик о том, что "надо отладить" - а понимание, что да почему, не получалось извлечь без мата, как у нас водится Была весьма объективная причина того, что разработка шла ни шатко, ни валко - известное по тем временам (более 10 лет назад) финансирование. Но существенную роль в этом играли и привычные средства формализации задач у разработчика - чисто "программистские", по умолчанию закладывающие пресловутый "семантический разрыв" между постановкой задачи и реализацией её решения.
Для преодоления этого разрыва вроде и предназначен техноязык и концепция гибридного программирования. Однако что получается в Ты-среде? Формализация на указанном языковом базисе ну никак не сократит затраты умственного труда (а моторики-то и концентрации внимания на цепочках операций сколько надо - частично об этом Станислав говорил в своих замечаниях
в теме "Улучшенные варианты..."). Дополнительной работой будет и постредактирование шаблонов трансляции до исходного текста. Добавим и то, что концепция отражения деталей содержания вершин в комментариях вместо схемной декомпозиции вершин делает переход от укрупнённых схем к детальным, от схем к тексту неочевидным. Поэтому взаимопонимание между "предметником", аналитиком и программистом не улучшится и по этой линии. Если вносить такую "избыточную сложность" в процессы разработки - на них будет потрачен лишний труд - причём для высокозатратных систем (в частности, требующих отработки тех или иных решений натурно), возможно, в очень существенных объёмах.
А ведь оборонная отрасль - это серьёзная статья расходов бюджета. Тот уровень вложений в неё, который достигнут сейчас - плод и благоприятной (до поры до времени, которая уже пока прошла) конъюнктуры, и концентрации на довольно ограниченном составе направлений строительства вооружённых сил (которые уже сейчас пытаются расширить) - тут никакого секрета нет. Излишние усилия - это повод к излишним затратам сил и средств. Их нужно будет перекачивать из других отраслей экономики - и вот уже повод (дополнительный по отношению к другим возможным) к сокращению бюджетного сектора, социальных выплат работающим, школьникам и студентам, пенсионерам... затрат на общегосударственные и/или региональные программы (поддержку предпринимательства, инфраструктуру). Не слишком ли дорого обойдётся "избыточная сложность" проектирования? И пусть каждый читающий задумается - а не затронут ли последствия принятия таких решений его самого и окружающих? И всё ли он сделал, чтобы развитие событий было более благоприятным?..
Приложимость столь жёстких оценок к конкретной ситуации с Ты-реализацией ДРАКОН-методологии, конечно, зависит от реальной ситуации упомянутого ознакомления. Учитывая характер отрасли, человеку "не допущенному" в детали вникать не следует - но это и необязательно. Достаточно очертить возникающее "поле возможностей" и дать оценки элементам этого поля - а люди причастные к вопросу пусть выбирают, какая более подходит к реальности. Для краткости возьму крайние случаи:
* если Ты-реализация была представлена как поисковая, показана принципиальная незавершённость синтеза языковых средств, потенциальная необходимость и более широким кругам (включая, возможно, самого адресата и тех профессионалов, которых он сочтёт нужным пригласить) включиться в этот процесс - то такое предложение следует признать корректным.
* если было представлено, что общее направление реализации правильное, и нужно только довести его, а то и "косметически улучшить" - то такое предложение следует считать некорректным - более того, дезориентирующим в отношении потенциального роста эффективности формализации реальных задач.
Будем надеяться, что адресаты предложения - люди разбирающиеся и способные формировать своё мнение. Впрочем, в данной ситуации скорее важно, чтобы они обладали ресурсами, позволяющими, восприняв существующие реализации как макеты для определения требований, создать своё решение - уже отвечающее принципам эргономичности пользования, когнитивного качества и формальности описания.
Наверное, возникнет и такой вопрос - а почему же это автор ещё не прорекламировал своё предложение (включённое в Драконографику)? Ведь именно для этого обычно хают чужое - чтобы хвалить свое? Ан нет - считаю, моё предложение в сегодняшнем виде как раз показывает, что синтез формального и эргономичного языкового базиса не закончен. Более того - поскольку принят принцип представления визуальными языками смысла одного текстового языка (семейства) - то и буде этот базис закончен, выбор его кем-либо полностью зависит от выбора (или невыбора) этого текстового языка. Готовы специалисты разрабатывать на Обероне - такое предложение они могут принять за основу (и то его должны критически рассмотреть и доработать ИТ-специалисты). Впрочем, общий подход к делу считаю правильным - дать по возможности базис языков с указанием всех "подводных камней", замеченных в ходе специфицирования. Вот такой результат можно принимать за основу - и если разработчик будет и для другого ТЯП визуализацию делать - кое-какие соображения могут пригодиться.Ограничиваться качественным определением счёл для себя целесообразным и исходя из принципа разделения труда, который нелишне применять и при некоммерческих разработках. И формирование замысла столь сложного изделия, как среда визуализации знаний, и воплощение его не обязательно д.б. делом только одного человека. И даже профессиональному сочинителю не зазорно обращаться к аудитории за оценками эффективности и гарантоспособности принятых решений - в конце концов, это им прежде всего визуализировать свои знания...
Вполне предсказуем и ещё вопрос - а понимает ли автор, как сложно реализовать гибридный прогязык - имея в виду, что сначала ещё надо составить его спецификацию, имея только текстовые спецификации прогязыков и качественное описание визуального импер-языка (имеются в виду дракон-тезисы)? И сколько информатически недоопределённых (часто объективно оставленных спецификаторами на усмотрение реализатора) вещей нужно прояснить, сколь сложные решения принять разработчику? А понимает - именно поэтому взялся не за полигибридный язык, а только за гибридизацию с одним Обероном. И здесь-то над рядом положений спецификации, при всём качестве перевода Свердлова (см. вложение в этом сообщении), нужно основательно размышлять. А если пытаться много языков гибридизировать, со всеми их особенностями и недостатками (описанными тем же Свердловым в обзоре, вложенном
в это же сообщение), то мы и получим то, что имеем (и на основании чего на различных форумах делаются выводы о качестве шампур-метода и методологии в целом - зачастую легковесные, по-видимому - но получающие "железобетонную" аргументацию свойствами доступной среды реализации).
Притом заметим себе - начинать нужно именно со свойств языков визуализации, прежде всего их когнитивного качества и в то же время - соответствия формализмам программирования (напомню хотя бы об отсутствии в дракон-алфавите визуального оператора, парного виопу Параллельный процесс - притом, что в прогязыках РВ такой оператор имеется)... И эту сторону обсуждать должны не программисты прежде всего, а "предметники". А тут уже в который раз:
Геннадий Тышов писал(а):
При разработке придерживался образцов В.Д. Паронджанова и Дамке.
А насколько сами образцы совершенны - по боку.
Замечу - данным образцам представления знаний это не упрёк - их авторы преследовали конкретные теоретические и практические цели, которые каждый "берущий за образец" должен прежде всего понять и соотнести с целями, которые ставит перед собой (и ставит перед ним время). А далее - творчески развить, исходя и из сегодняшего положения дел. Здесь этого, увы, не видно.
Ох, недаром Эдуард Ильченко в конце концов заговорил об "альтернативном редакторе"... Но в основу любого такого редактора (включая и альтернативную версию Ты-среды, если Геннадий Николаевич сочтёт возможным её делать) д.б. положена именно готовая спецификация гибридного "графитного" языка (как и компиляторы Оберона делались по обсуждённым спецификациям - пусть не все результаты обсуждения принимал сам Вирт) - нельзя ставить телегу впереди лошади. А дальше надо аккуратно строить модель реализации (уже профессионалам) - чтобы не получалось, как с алгоритмом перечерчивания, где, как выяснилось
в теме "Как увеличить скорость работы дракон-редактора", изначально был заложен алгоритм квадратичной сложности - а можно было обойтись меньшей...
А была бы разработка открытая, начиная со спецификации реализуемых языков - могли бы подключиться не отдельные коллеги (вроде того, о ком идёт речь здесь):
Недавно товарищ (на форуме не был), прислал модуль, позволяющий избавиться от эффекта мерцания при перерисовке экрана, также собирается заняться выгрузкой в формате XML.
- а более широкий круг. Уже тот уровень описания своих решений, который продемонстрировал Дмитрий_ВБ, представляется вполне приемлемым. И Станислав Тарасенко
в теме "Дракон-схемы => на любой прогязык" тоже. В эту строку и такое лыко:
Геннадий Тышов писал(а):
Не знаю, справлюсь ли с описанием.
В принципе разработчика "на общественных началах" никто не может заставить делать полностью законченный по профессиональным требованиям продукт. Само по себе описание, вообще говоря, м.б. сформировать легче, пользуясь результатами работы с продуктом - и для этого вроде бы предназначены темы, связанные с Ты-средой. Но их материал надо использовать, "втаскивая" в целостно организованную Справку. И даже это в принципе мог бы делать не сам разработчик (хотя бы предварительно) - но при определённом достигнутом уровне качества и самого изделия и конечной формы документации на него.
Как пример - сделал я проект инструкции на среду аналогичного назначения - пакет DesignIDEF (то и другое для ознакомления можно найти в загрузках на этой странице). Но это было возможно даже до такого уровня довести прежде всего потому, что не нужно было знакомиться с "фичами и багами" этого изделия - просто берёшь и изучаешь режимы, команды, смотришь по необходимости в англоязычную Справку (кстати, хоть она и прилично организована - необходимости такой особо не возникало - сам интерфейс удобен для изучения).
Притом назначение визуализации этот пакет уже в 1995 году реализовывал лучше - абстрагируясь от сути заложенных в нём методологий. Но и они сложнее в реализации, чем техноязык в Ты-версии - хотя бы заложенная поддержка смены грамматики IDEF-дуг уже не вполне тривиальна...
И вот снова возникает вопрос - а может, это какая-то чудодейственная технология и средства РПО (по сравнению с ООП на Дельфи) была использована в начале 1990-х? А уже серьёзно - не следует ли поискать другую среду, другой язык программирования средств визуализации?
P.S. Сказанное не значит, что не нужно искать каких либо альтернативных подходов к визуализации - тем более, что техноязык в авторском определении, как уже отмечалось, неполон по отношению к реальной совокупности визуализируемых знаний - и значит, нужно было в любом случае каждому на этих направлениях предлагать что-то своё. Вопрос только в том, как формируются решения - те же Дамке-схемы - вот Прохоров тоже предлагал "развёрнутое" представление, и тоже, как я понимаю, для полиязыкового описания - но оно почему-то воспринимается лучше (в т.ч. и за счёт своего рода свёртки кода - только не в графические, а в текстовые блоки, насколько можно видеть на скриншоте Фиг.12 из
вложения в это сообщение). И вот такое заявление:
Геннадий Тышов писал(а):
Реализации свертки участков не планируется, как же, можно ставить вопрос о масштабировании изображения.
не очень понятно...
Кстати, у Прохорова упоминается и о поддержке ведения не только версий, но и вариантов разработки - очевидно, то же, что подразумевает диспозитивное применение вершины Область и каталогизация областей-вариантов, как определено, допустим,
в этом сообщении. Многое подлежит поиску и обсуждению - если захотеть качественного результата...