DRAKON.SU

Текущее время: Четверг, 22 Февраль, 2018 03:52

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 380 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14, 15, 16 ... 19  След.
Автор Сообщение
 Заголовок сообщения: В чём рисовать блок-схемы?
СообщениеДобавлено: Среда, 30 Июнь, 2010 22:48 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Geratewart писал(а):
Нельзя ли добавить в программу обычные гостовские блоки (развилка-ромб, параллелограмм-ввод)?
Ведь в ВУЗах требуют обычные гостовские блок-схемы, и студенты и аспиранты рисуют их в графических редакторах...


Приложение вот из этого сообщения пошло бы... но там только развилка и действие, как я понимаю...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Четверг, 01 Июль, 2010 14:11 

Зарегистрирован: Пятница, 07 Май, 2010 14:10
Сообщения: 7
Уважаемый Геннадий Николаевич,

Прошу добавить следующий функционал:
1.Выделяешь иконки с помощью мышки, (как в виндовсе)
2. Выделенные иконки подсвечиваются синим цветом
3. Нажимаешь Ctrl + c (Ctral +x)
4. Выделяешь узел
5. Нажимаешь Ctrl + v
6. Получаешь копирование (вставку)

т.е. стандартный механизм копирования.
Это обязательно надо сделать!!!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Четверг, 05 Август, 2010 19:30 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
Geratewart писал(а):
Вопрос автору программы. Нельзя ли добавить в программу обычные гостовские блоки (развилка-ромб, параллелограмм-ввод)?
Ведь в ВУЗах требуют обычные гостовские блок-схемы, и студенты и аспиранты рисуют их в графических редакторах...


Простите, что влез. Посмотрите, пожалуйста, здесь:
viewtopic.php?f=79&t=2689
четвёртое сообщение снизу Геннадия Тышова - оно для Вас. Геннадий Николаевич согласен и пишет:
"Нужен перечень Драконовских икон с отображением в ГОСТовском начертании."

Предложите?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Вторник, 14 Сентябрь, 2010 16:40 

Зарегистрирован: Пятница, 07 Май, 2010 14:10
Сообщения: 7
Ну не хватает для некоторых схем размер графического поля 3500 на 2500 :(
Параджанов писал, что схема может при необходимости занимать много места (для обеспечения наглядности), а в редакторе к сожалению стоит органичение.
Хоро было бы расширить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Вторник, 14 Сентябрь, 2010 18:19 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
odinets писал(а):
т.е. стандартный механизм копирования.
Это обязательно надо сделать!!!

odinets писал(а):
Ну не хватает для некоторых схем размер графического поля 3500 на 2500.
Хорошо было бы расширить.

Да, это сделано. Выпуск будет в ближайшее время, через 1, 2 дня.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Среда, 15 Сентябрь, 2010 09:33 

Зарегистрирован: Пятница, 07 Май, 2010 14:10
Сообщения: 7
Спасибо и наилучшие пожелания


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Четверг, 16 Сентябрь, 2010 10:02 

Зарегистрирован: Четверг, 04 Июнь, 2009 15:08
Сообщения: 100
odinets писал(а):
Ну не хватает для некоторых схем размер графического поля 3500 на 2500 :(
Параджанов писал, что схема может при необходимости занимать много места (для обеспечения наглядности), а в редакторе к сожалению стоит органичение.
Хоро было бы расширить.


Если просто взять и расширить, будет долго грузиться и сожрёт всю оперативку. Если все новые версии будут с большим полем, на старых компьютерах программа запускаться не будет. Лучше сделать несколько вариантов программы - для разный полей. И это так просто!

Мой вам совет. Возьмите Ресторатор, найдите поиском 3500 и замените на большее число, и 2500 (рядом) тоже. Сохраните и запустите. Будет Всё будет работать, вот вам крест! Я сам так делал (вот тут: download/file.php?id=1685 в папке "Программы), но там староватая версия Дракон-редактора, ещё и немного изменённая. Хотя можете попробовать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Четверг, 16 Сентябрь, 2010 10:27 

Зарегистрирован: Пятница, 07 Май, 2010 14:10
Сообщения: 7
Почему-то не получилось нормально распаковать архив.
Выдает сообщение:
"! C:\Users\aodinets\Desktop\Дракон - куда хошь 12 авг 2010.zip: Cannot create Дракон 12 авг 2010\Перевод схем на текстовый прогязык\Схема >>> текст.exe
! Хибний синтаксис імені файлу, каталогу або позначки тому.
! C:\Users\aodinets\Desktop\Дракон - куда хошь 12 авг 2010.zip: Attempting to correct the invalid file name
! C:\Users\aodinets\Desktop\Дракон - куда хошь 12 авг 2010.zip: Renaming Дракон 12 авг 2010\Перевод схем на текстовый прогязык\Схема >>> текст.exe to Дракон 12 авг 2010\Перевод схем на текстовый прогязык\Схема ___ текст.exe
"
Это только у меня так?

Интересно, когда нибудь выйдет коммерческая версия Дракон-редактора?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Ноябрь, 2010 05:06 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Драконограф в viewtopic.php?p=53379#p53379 писал(а):
Согласен - это дополнительная форма представления, только прежде всего не алгоритма, а системы алгоритмов - чтобы можно было её "охватить одним взглядом" (симультанно). Только для этого нужна возможность свёртки линейных участков, о чём говорил выше.
Геннадий Тышов в viewtopic.php?p=53386#p53386 писал(а):
В перспективе некоторые детали надо переделать, улучшить, но в основном постановка и интерфейс стабилизировались.

Геннадий Тышов в viewtopic.php?p=53276#p53276 писал(а):
... Нет привязки к конкретному языку программирования и предусматривает внимание на алгоритме в проблемной области.
В ваших ссылках использованы конкретные языки программирования с изменением формы записи.

К вопросу о трансляции. Среда Drakon предлагает хранение программных текстов в полях алгоритма и формирование шаблона текста программного кода модуля...

Становится необходимым снова взглянуть на контекст, в котором принимаются решения, подобные обсуждаемому в этой теме. Можно было бы ограничиться сказанным в этом сообщении и на этой странице - но некоторые обстоятельства обусловливают необходимость высказаться "резче и грубее", как говорит Владимир Даниелович :)
Так, только недавно в сообщении о роли ГНОМа говорил об необходимости внедрения эргономичных решений в практику, тем более в критических отраслях - и вот:
Геннадий Тышов в viewtopic.php?p=34256#p34256 писал(а):
С языком ДРАКОН и и.с. DRAKON познакомил программистов (одного из ведущих) Севмашпредприятия. Заинтересовались и попросили разрешение выложить материалы в свободном доступе во внутризаводском интернете. Дал согласие, об использовании на сегодня ничего не знаю.

Само по себе предложение ко внедрению конкретной реализации правильно и своевременно - пора уже выходить в практику. Интересен был бы опыт внедрения - но оборонная сфера такова, что даже изложенный обезличенно в отношении разрабатываемых объектов, он может содержать элементы охраняемых сведений - и потому мы не вправе в общем случае просить об ознакомлении. Ну а в частности - захотят представители такого рода организации в установленном порядке сформировать через соответствующие службы сообщение о результатах и представить его в т.ч. на данную конференцию - скажем им за это спасибо :) Лишний раз стоит поблагодарить и Геннадия Николаевича - никто ведь его не заставляет заниматься развитием Ты-среды и не стимулирует :)
Вместе с тем потенциальная возможность использования именно в такой сфере данной реализации - и фактически установленного ею стандарта на семейство языков визуализации и на технологию автоматизированного описания задач - вызывает серьёзные вопросы.

Что практически даст внедрение указанной реализации техноязыка? Свойствами Ты-среды как инфопрогизделия можно для начала пренебречь - хотя по теме "Тестирование и.с. Drakon" ясно, что это продукт поисковый, не промышленный. Но и свойства языкового базиса, как он определён Геннадием Николаевичем (ДРАКОН+ГНОМ+Дамке-схемы), не позволяют считать его вполне эргономичным средством представления знаний.
Здесь уже говорилось (Ильёй Евгеньевичем, Фёдором Васильевичем) о том, что механизмы языка д.б. обоснованы требованиями к качеству разрабатываемой на нём системы. В этом смысле исходный техноязык неполон - к алгоритмам всё не сводится. В Ты-среде по-своему он восполняется - но как? Дамке-деревья с возвратами нарушают целостность восприятия, требуя обратного следования по цепям. Про роль ГНОМа уже сказал достаточно в упомянутом сообщении. Деклар-языка визуального как не было, так и нет. И вспомогательных элементов визуализации (КогниСтиль и пр.) тоже. Если принимать за основу разработки не то, что саму Ты-среду - но просто её концептуальные решения - говорить об "улучшении работы ума" над задачами в такой среде не считаю возможным - как бы не было ухудшения по сравнению с тем же Блэкбоксом...
    Вспоминается такой эпизод. Как-то на учебной практике присутствовал при работе разработчика программно-аппаратных устройств с заказчиком в роли "ученика аналитика". В детали не вникал - извлекал для себя именно суть процесса взаимодействия. А получалось вот что - представители заказчика в погонах вплоть до беспросветных пытались разобраться, почему же это образец устройства не делает того, что положено по техзаданию. И не получалось у них взаимопонимания - заказчик о несоответствии показателям, а разработчик о том, что "надо отладить" - а понимание, что да почему, не получалось извлечь без мата, как у нас водится ;) Была весьма объективная причина того, что разработка шла ни шатко, ни валко - известное по тем временам (более 10 лет назад) финансирование. Но существенную роль в этом играли и привычные средства формализации задач у разработчика - чисто "программистские", по умолчанию закладывающие пресловутый "семантический разрыв" между постановкой задачи и реализацией её решения.
Для преодоления этого разрыва вроде и предназначен техноязык и концепция гибридного программирования. Однако что получается в Ты-среде? Формализация на указанном языковом базисе ну никак не сократит затраты умственного труда (а моторики-то и концентрации внимания на цепочках операций сколько надо - частично об этом Станислав говорил в своих замечаниях в теме "Улучшенные варианты..."). Дополнительной работой будет и постредактирование шаблонов трансляции до исходного текста. Добавим и то, что концепция отражения деталей содержания вершин в комментариях вместо схемной декомпозиции вершин делает переход от укрупнённых схем к детальным, от схем к тексту неочевидным. Поэтому взаимопонимание между "предметником", аналитиком и программистом не улучшится и по этой линии. Если вносить такую "избыточную сложность" в процессы разработки - на них будет потрачен лишний труд - причём для высокозатратных систем (в частности, требующих отработки тех или иных решений натурно), возможно, в очень существенных объёмах.

А ведь оборонная отрасль - это серьёзная статья расходов бюджета. Тот уровень вложений в неё, который достигнут сейчас - плод и благоприятной (до поры до времени, которая уже пока прошла) конъюнктуры, и концентрации на довольно ограниченном составе направлений строительства вооружённых сил (которые уже сейчас пытаются расширить) - тут никакого секрета нет. Излишние усилия - это повод к излишним затратам сил и средств. Их нужно будет перекачивать из других отраслей экономики - и вот уже повод (дополнительный по отношению к другим возможным) к сокращению бюджетного сектора, социальных выплат работающим, школьникам и студентам, пенсионерам... затрат на общегосударственные и/или региональные программы (поддержку предпринимательства, инфраструктуру). Не слишком ли дорого обойдётся "избыточная сложность" проектирования? И пусть каждый читающий задумается - а не затронут ли последствия принятия таких решений его самого и окружающих? И всё ли он сделал, чтобы развитие событий было более благоприятным?..

Приложимость столь жёстких оценок к конкретной ситуации с Ты-реализацией ДРАКОН-методологии, конечно, зависит от реальной ситуации упомянутого ознакомления. Учитывая характер отрасли, человеку "не допущенному" в детали вникать не следует - но это и необязательно. Достаточно очертить возникающее "поле возможностей" и дать оценки элементам этого поля - а люди причастные к вопросу пусть выбирают, какая более подходит к реальности. Для краткости возьму крайние случаи:
    * если Ты-реализация была представлена как поисковая, показана принципиальная незавершённость синтеза языковых средств, потенциальная необходимость и более широким кругам (включая, возможно, самого адресата и тех профессионалов, которых он сочтёт нужным пригласить) включиться в этот процесс - то такое предложение следует признать корректным.
    * если было представлено, что общее направление реализации правильное, и нужно только довести его, а то и "косметически улучшить" - то такое предложение следует считать некорректным - более того, дезориентирующим в отношении потенциального роста эффективности формализации реальных задач.
Будем надеяться, что адресаты предложения - люди разбирающиеся и способные формировать своё мнение. Впрочем, в данной ситуации скорее важно, чтобы они обладали ресурсами, позволяющими, восприняв существующие реализации как макеты для определения требований, создать своё решение - уже отвечающее принципам эргономичности пользования, когнитивного качества и формальности описания.

Наверное, возникнет и такой вопрос - а почему же это автор ещё не прорекламировал своё предложение (включённое в Драконографику)? Ведь именно для этого обычно хают чужое - чтобы хвалить свое? ;) Ан нет - считаю, моё предложение в сегодняшнем виде как раз показывает, что синтез формального и эргономичного языкового базиса не закончен. Более того - поскольку принят принцип представления визуальными языками смысла одного текстового языка (семейства) - то и буде этот базис закончен, выбор его кем-либо полностью зависит от выбора (или невыбора) этого текстового языка. Готовы специалисты разрабатывать на Обероне - такое предложение они могут принять за основу (и то его должны критически рассмотреть и доработать ИТ-специалисты). Впрочем, общий подход к делу считаю правильным - дать по возможности базис языков с указанием всех "подводных камней", замеченных в ходе специфицирования. Вот такой результат можно принимать за основу - и если разработчик будет и для другого ТЯП визуализацию делать - кое-какие соображения могут пригодиться.
Ограничиваться качественным определением счёл для себя целесообразным и исходя из принципа разделения труда, который нелишне применять и при некоммерческих разработках. И формирование замысла столь сложного изделия, как среда визуализации знаний, и воплощение его не обязательно д.б. делом только одного человека. И даже профессиональному сочинителю не зазорно обращаться к аудитории за оценками эффективности и гарантоспособности принятых решений - в конце концов, это им прежде всего визуализировать свои знания...

Вполне предсказуем и ещё вопрос - а понимает ли автор, как сложно реализовать гибридный прогязык - имея в виду, что сначала ещё надо составить его спецификацию, имея только текстовые спецификации прогязыков и качественное описание визуального импер-языка (имеются в виду дракон-тезисы)? И сколько информатически недоопределённых (часто объективно оставленных спецификаторами на усмотрение реализатора) вещей нужно прояснить, сколь сложные решения принять разработчику? А понимает :) - именно поэтому взялся не за полигибридный язык, а только за гибридизацию с одним Обероном. И здесь-то над рядом положений спецификации, при всём качестве перевода Свердлова (см. вложение в этом сообщении), нужно основательно размышлять.
А если пытаться много языков гибридизировать, со всеми их особенностями и недостатками (описанными тем же Свердловым в обзоре, вложенном в это же сообщение), то мы и получим то, что имеем (и на основании чего на различных форумах делаются выводы о качестве шампур-метода и методологии в целом - зачастую легковесные, по-видимому - но получающие "железобетонную" аргументацию свойствами доступной среды реализации).

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

А насколько сами образцы совершенны - по боку.
    Замечу - данным образцам представления знаний это не упрёк - их авторы преследовали конкретные теоретические и практические цели, которые каждый "берущий за образец" должен прежде всего понять и соотнести с целями, которые ставит перед собой (и ставит перед ним время). А далее - творчески развить, исходя и из сегодняшего положения дел. Здесь этого, увы, не видно.
Ох, недаром Эдуард Ильченко в конце концов заговорил об "альтернативном редакторе"... Но в основу любого такого редактора (включая и альтернативную версию Ты-среды, если Геннадий Николаевич сочтёт возможным её делать) д.б. положена именно готовая спецификация гибридного "графитного" языка (как и компиляторы Оберона делались по обсуждённым спецификациям - пусть не все результаты обсуждения принимал сам Вирт) - нельзя ставить телегу впереди лошади. А дальше надо аккуратно строить модель реализации (уже профессионалам) - чтобы не получалось, как с алгоритмом перечерчивания, где, как выяснилось в теме "Как увеличить скорость работы дракон-редактора", изначально был заложен алгоритм квадратичной сложности - а можно было обойтись меньшей...

А была бы разработка открытая, начиная со спецификации реализуемых языков - могли бы подключиться не отдельные коллеги (вроде того, о ком идёт речь здесь):
Геннадий Тышов в viewtopic.php?p=46802#p46802 писал(а):
Недавно товарищ (на форуме не был), прислал модуль, позволяющий избавиться от эффекта мерцания при перерисовке экрана, также собирается заняться выгрузкой в формате XML.
- а более широкий круг. Уже тот уровень описания своих решений, который продемонстрировал Дмитрий_ВБ, представляется вполне приемлемым. И Станислав Тарасенко в теме "Дракон-схемы => на любой прогязык" тоже. В эту строку и такое лыко:
Геннадий Тышов писал(а):
Не знаю, справлюсь ли с описанием.

В принципе разработчика "на общественных началах" никто не может заставить делать полностью законченный по профессиональным требованиям продукт. Само по себе описание, вообще говоря, м.б. сформировать легче, пользуясь результатами работы с продуктом - и для этого вроде бы предназначены темы, связанные с Ты-средой. Но их материал надо использовать, "втаскивая" в целостно организованную Справку. И даже это в принципе мог бы делать не сам разработчик (хотя бы предварительно) - но при определённом достигнутом уровне качества и самого изделия и конечной формы документации на него.
    Как пример - сделал я проект инструкции на среду аналогичного назначения - пакет DesignIDEF (то и другое для ознакомления можно найти в загрузках на этой странице). Но это было возможно даже до такого уровня довести прежде всего потому, что не нужно было знакомиться с "фичами и багами" этого изделия - просто берёшь и изучаешь режимы, команды, смотришь по необходимости в англоязычную Справку (кстати, хоть она и прилично организована - необходимости такой особо не возникало - сам интерфейс удобен для изучения).
    Притом назначение визуализации этот пакет уже в 1995 году реализовывал лучше - абстрагируясь от сути заложенных в нём методологий. Но и они сложнее в реализации, чем техноязык в Ты-версии - хотя бы заложенная поддержка смены грамматики IDEF-дуг уже не вполне тривиальна...

И вот снова возникает вопрос - а может, это какая-то чудодейственная технология и средства РПО (по сравнению с ООП на Дельфи) была использована в начале 1990-х? А уже серьёзно - не следует ли поискать другую среду, другой язык программирования средств визуализации?

P.S. Сказанное не значит, что не нужно искать каких либо альтернативных подходов к визуализации - тем более, что техноязык в авторском определении, как уже отмечалось, неполон по отношению к реальной совокупности визуализируемых знаний - и значит, нужно было в любом случае каждому на этих направлениях предлагать что-то своё. Вопрос только в том, как формируются решения - те же Дамке-схемы - вот Прохоров тоже предлагал "развёрнутое" представление, и тоже, как я понимаю, для полиязыкового описания - но оно почему-то воспринимается лучше (в т.ч. и за счёт своего рода свёртки кода - только не в графические, а в текстовые блоки, насколько можно видеть на скриншоте Фиг.12 из вложения в это сообщение). И вот такое заявление:
Геннадий Тышов писал(а):
Реализации свертки участков не планируется, как же, можно ставить вопрос о масштабировании изображения.
не очень понятно...
Кстати, у Прохорова упоминается и о поддержке ведения не только версий, но и вариантов разработки - очевидно, то же, что подразумевает диспозитивное применение вершины Область и каталогизация областей-вариантов, как определено, допустим, в этом сообщении. Многое подлежит поиску и обсуждению - если захотеть качественного результата...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Ноябрь, 2010 06:32 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Геннадий Тышов в viewtopic.php?p=53443#p53443 писал(а):
Не моя задача, выполнять ревизию реализуемых языков.
Видите ли, Геннадий Николаевич... Введением разновидовых приложений Ты-объектов, участвующих в формировании "текстового отчёта" о Ты-модели (в Ваших терминах - в сборке текста), Вы фактически провели ревизию относительно "классического" определения ДРАКОН-методологии. В чём она состоит? Паронджанов предполагает (если я не прав - он меня поправит), что сочинитель детализирует деятельность как дракон-схему (комплекс дракон-схем, который я называю дракон-моделью) - пока не придёт к языку текстоэлементов настолько формальному, насколько ему необходимо - в пределе к гибридному прогязыку. При использовании текстовых приложений, имеющих смысл информатически полуформальный (алгоритмические) и формальный (программные) предполагается, что сочинитель, как правило, составляет только дракон-эскиз - а детали описывает текстом приложений. Это не упрощает моделирование итеративное, с пересмотром в ходе детализации укрупнённого описания - сочинитель неявно ориентируется на "конспектирование" решения вместо его визуализации. Конечно, ему вроде ничего не мешает пользоваться только управленческим приложением (отражая в нём неформальный смысл сопряжённого объекта Ты-модели и иные соображения для дальнейшей ориентировки) и детализировать схемы... но шаблон исхтекста-то собирается именно по приложениям остальных видов (поправьте меня, если это неверно)... а ориентации визуального синтаксиса на маршрутные структуры, реально описывающие маршруты процесса, в Ты-версии техноязыка нет (рассуждения вроде теоремы Бома-Джакопини о базовых структурах представления деятельности для этой цели слишком общие - нужны конкретные категории визуальных операторов).
Отмечу и то, что материал Драконографики предлагается для обсуждения, предшествующего реализации. Любое же готовое изделие формализации (и Ты-среда в частности) предлагает уже к пользованию и язык, и технологию. Это и Вы понимаете - см. хотя бы это: "DRAKON – это прототип и инструмент для специалистов, разработчиков будущих программ - сред применения языка Дракон...
Устанавливает для них, де-факто, стандарт реализации языка Дракон для всех областей применения." (Справка к Ты-среде от 30.07.2010, Разд. 1) - но это и так логически очевидно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Суббота, 13 Ноябрь, 2010 12:38 

Зарегистрирован: Суббота, 13 Ноябрь, 2010 12:32
Сообщения: 4
Здравствуйте! Ваша программа наглядно отображает алгоритмы

Возможно ли добавить следующие функции?
1. Возможность экспорта в графический формат или вывод на печать
2. Возможность перетаскивать связи и блоки мышкой


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Суббота, 13 Ноябрь, 2010 20:09 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
lyubimov.maxim

1. В контекстных меню листа и схемы есть пункты копирования в графический файл и в системный буфер.

2. Перетаскивание мышкой не планируется, ограничились копированием через графический буфер, т.к. это более универсальный способ.

Обращу ваше внимание, последний тестовый выпуск в теме "Тестирование и.с. Drakon" http://forum.oberoncore.ru/viewtopic.php?p=53839#p53839.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Воскресенье, 14 Ноябрь, 2010 09:41 

Зарегистрирован: Суббота, 13 Ноябрь, 2010 12:32
Сообщения: 4
Большие блоки (переключатель) не копируются через буфер, а иногда надо использовать аналогичные конструкции в программе, быстрее было бы просто скопировать уже готовую и отредактировать текст.

Было бы хорошо сделать масштабирование, что бы можно было более полно воспринимать и проще редактировать большие схемы.

Есть вопрос, в справке ответа не нашёл, в и. с. Дракон можно непосредственно производить трансляцию схемы в код? Если да, то как?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Воскресенье, 14 Ноябрь, 2010 14:32 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
1. Блоки, в т.ч. переключатель, нельзя скопировать выбором 1-й иконы.
Производится выбор шампур-блока.
В справке "Работа в и.с. DRAKON" пункт "Мышка"
Цитата:
LeftMouse+Движение или RightMouse+Движение: производится выбор шампур-блока. Выбор отображается пунктирной рамкой.

Рекомендуется помещать рамку с левым верхним углом левее верхней точки ввода на шампуре и правым нижним углом правее ниже нижней точки ввода или узла на том же шампуре.

При отпускании клавиши производится анализ правильности выбора для шампур-блока. При правильном выборе отмечаются входящие иконы и узлы, иначе выдается сообщение «Выбранный блок не допускает использование».

При выборе правой клавишей (RightMouse) выдается контекстное меню.
Так же смотрите справку "Вопросы и ответы" пункт 7, "Реализация языка Дракон" пункт 10.

2. Реализация масштабирования отложена на будущее.

3. Да, схемы нельзя транслировать в исполняемый код, т.к. в схемах алгоритм, а не программный текст. Предусмотрено интегрирование со средами разработки для языков программирования. Формируются шаблоны программного кода по модели конечного автомата. Смотрите справку "Программирование, синтез ПО"


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Среда, 17 Ноябрь, 2010 08:14 

Зарегистрирован: Суббота, 13 Ноябрь, 2010 12:32
Сообщения: 4
Как избавиться от пересекающихся линий, когда есть множество условий, если операция обновить не помогает? Я использую последнюю версию.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Среда, 17 Ноябрь, 2010 19:16 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
lyubimov.maxim

Алгоритма раскладки графа полностью без пересечений у меня нет.
Соответственно, "Обновить" выполняет раскладку по возможности, а остальное придется улучшить вручную. Надо наработать навык.

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

При перемещении мышкой: меняется вид курсора, у иконы или узла отображаются новые положения вертикалей и горизонталей.
Так же перемещать выбранную икону или узел можно, при нажатом Shifte-е, клавишами со стрелками.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Среда, 17 Ноябрь, 2010 23:07 

Зарегистрирован: Суббота, 13 Ноябрь, 2010 12:32
Сообщения: 4
Спасибо за помощь


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Среда, 12 Январь, 2011 09:08 

Зарегистрирован: Среда, 12 Январь, 2011 09:00
Сообщения: 12
Скачал DRAKON_2010_06_01
DRAKON.exe запускается с ошибкой "Недостаточно памяти для обработки команды". После этого вижу окно программы, но ничего сделать не удается. При попытке создать новый лист вижу ошибку "Cannot assign a nil to a TFont". После этой ошибки не удается даже закрыть программу.
Запускаю под Windows Vista.

Научите, как все-таки посмотреть ваше творение?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Среда, 12 Январь, 2011 16:21 

Зарегистрирован: Среда, 12 Январь, 2011 09:00
Сообщения: 12
Удалось запустить. Видимо дело было в нехватке ресурсов. Вообще-то подобного рода ошибки легко отлавливаются. И было бы нелишним выдавать более внятные сообщения об ошибках.

Впечатления:
1. УЖАСНОЕ меню (как главное, так и контекстное). Другого слова не подберу.
2. Не хватает панели инструментов. Я первый раз вижу программу и довольно слабо разбираюсь в предметной области, но прежде чем я смог хоть что-то сделать я чуть глаза не сломал, изучая меню. Мне было бы гораздо проще, если бы доступные действия были представлены в виде кнопок: кнопка доступна - можно пользоваться, недоступна - нельзя.
3. MDI-интерфейс просится так, что просто сил нет. Как мне делать новую схему, основываясь на уже существующей? Никак... Я не могу видеть сразу две или больше схем, только одну - ту, которую редактирую.
4. Схемы лежат стопочкой. Почему выбранная мной схема меняет положение в стопке? Почему она не становится просто полностью видимой, не прыгая куда-то в другое место? Это вызывает некую оторопь...
5 Выделение мышкой. Не понимаю, что и как можно выделить, но это не так уж и страшно. Но каждый раз видеть сообщение "Выбранный блок не допускает использование" просто-напросто НАДОЕЛО. Раз я ничего не выделил (не важно по какой причине), то и делать ничего не надо. Зачем мне видеть КАЖДЫЙ РАЗ одно и то же уведомление? И потом - что за "выбранный блок"? Я же ничего не выбрал, по крайней мере я не вижу ничего, что было бы хотя бы отдаленно похоже на выбранный блок. Или имеется в виду тот самый пунктирный прямоугольник? Не понимаю...
6. Что такое "гр. буфер" и "буфер текста"? В Windows есть единый буфер обмена, в котором может храниться все, что угодно, правда в единственно экземпляре. Если Вы пытаетесь расширить его функциональность, то почему таким необычным способом? Word, например, дает не самый худший образец...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: DRAKON - Интегрированная среда
СообщениеДобавлено: Среда, 12 Январь, 2011 18:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
spinmozg писал(а):
Удалось запустить. Видимо дело было в нехватке ресурсов. Вообще-то подобного рода ошибки легко отлавливаются. И было бы нелишним выдавать более внятные сообщения об ошибках.

Впечатления:
...

Все перечисленное выше - это просто первый беглый взгляд. Есть там еще чисто программные ошибки, типа пропускаемых событий мыши и прочие мелочи... Если интересно, то я по мере изучения могу писать о найденных ошибках и недостатках.
Вы знаете, со всем перечисленным выше (что я выпустил в цитате) скорее всего в эту тему: viewtopic.php?f=79&t=3091
Так как это как раз и есть эргономика (в т.ч. когнитивная) - только уже не языка, а среды его поддержки...
Не знаю только, как насчёт перспектив удовлетворения... хоть указанная тема и называется "Новые требования..." - а в принципе-то всё сказанное там (и Вами здесь) - вещи достаточно естественные...
    Также нужно придерживаться формата - см. это сообщение. Т.к. мне Ваши замечания в этой части показались интересными - для начала переоформил сам в той же теме, как можно видеть.

А с остальным (насчёт ресурсов и чисто программных) - по-видимому, в эту тему: viewtopic.php?f=79&t=2689
Вот там, как можно видеть, заявки как-то удовлетворяются :) Только их тоже нужно оформлять аналогично.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 380 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14, 15, 16 ... 19  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2017, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB