DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 12:25

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




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Ещё отзывы о Драконе
СообщениеДобавлено: Среда, 07 Май, 2008 12:49 

Зарегистрирован: Среда, 07 Май, 2008 12:25
Сообщения: 15
Владимир Даниелович, большое Вам спасибо за отличные книги, за язык Дракон!

В своей работе на ниве юзабилити сталкиваюсь с самыми большими трудностями именно на фронте общения, обмена идеями. Язык в этом плане просто глоток свежего воздуха! Его удобно использовать, но хочется, что бы было ещё удобнее. Вы подробно описали в своей книге концепцию графического редактора для языка. Нужны доступные инструменты. Есть ли возможность пустить в массы то, что применяется в ракетно-космической отрасли?

Интересно было бы узнать о возможностях применения Языка для проектирования интерфейса человек-компьютер. Этот ракурс разработки программных комплексов в настоящее время тоже обделён в части графического языка.

Крепкого Вам здоровья и горячее пожелание принятия языка Дракон в качестве стандарта преподавания информатики в системе образования нашей Родины!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Среда, 07 Май, 2008 13:33 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Андрей Федяев писал(а):
Есть ли возможность пустить в массы то, что применяется в ракетно-космической отрасли?

Есть. Есть даже инструмент, доступный для тестирования, в соседней теме форума. Есть даже опыт применения в бизнес-среде, для описания бизнес-процессов. Есть даже желание (у меня) сделать полноценный компилятор.

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

Что же получается? Как полноценный язык для разработки - не годится.
Как эргономичная визуальная настройка над ассемблером - не годится.
Для формального описания бизнес-процессов и "чистых алгоритмов" - самое то.

Получается немного грустно - замечательная сама по себе идея вроде бы имеет ограниченную область применения (примерно как одна диаграмма из набора UML).

Андрей Федяев писал(а):
Интересно было бы узнать о возможностях применения Языка для проектирования интерфейса человек-компьютер. Этот ракурс разработки программных комплексов в настоящее время тоже обделён в части графического языка.

Интересно, как Вы себе это представляете?
По моему мнению, 30% в интерфейсе человек-компьютер (HMI) составляет дизайн, 50% - эргономика (этим пунктом почти никто, кстати, не занимается, потому имеем то, что имеем - неудобоваримое оконное мышекликанье). Ну и остальные 20% занимает собственно рекация элементов интерфейса на действия пользователя. Причём 90% здесь - стандартное поведение элементов GUI, а 10% - собственно та часть, где можно применить Дракон - логика (сценарий) использования. Или, по-другому, Use Case.

Так стоит ли овчинка выделки? Возможно, стоит, если вспомнить о тех 50% аспектов эргономики, про которые забывают почти все программисты.

Андрей Федяев писал(а):
пожелание принятия языка Дракон в качестве стандарта преподавания информатики в системе образования нашей Родины!

Предлагаю всё же не торопиться. Без сомнения, подобный визуальный язык значительно полезнее для алгоритмического мышления, чем изучаемый во многих школах Бейсик... Но Дракон можно и нужно улучшить, если уж мы хотим сделать его универсальным и стандартным. Думаю, все здесь присутствующие в этом заинтересованы. Будем думать и работать вместе!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Среда, 07 Май, 2008 15:07 

Зарегистрирован: Среда, 07 Май, 2008 12:25
Сообщения: 15
Alexey_Donskoy писал(а):
Есть. Есть даже инструмент, доступный для тестирования, в соседней теме форума.

Спасибо за наводку!

Alexey_Donskoy писал(а):
Интересно, как Вы себе это представляете?
По моему мнению, 30% в интерфейсе человек-компьютер (HMI) составляет дизайн, 50% - эргономика (этим пунктом почти никто, кстати, не занимается, потому имеем то, что имеем - неудобоваримое оконное мышекликанье). Ну и остальные 20% занимает собственно рекация элементов интерфейса на действия пользователя. Причём 90% здесь - стандартное поведение элементов GUI, а 10% - собственно та часть, где можно применить Дракон - логика (сценарий) использования. Или, по-другому, Use Case.

Так стоит ли овчинка выделки? Возможно, стоит, если вспомнить о тех 50% аспектов эргономики, про которые забывают почти все программисты.

Спасибо за Ваше мнение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Воскресенье, 11 Май, 2008 20:11 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Уважаемый Андрей Федяев!

Из Вашего первого сообщения как будто следует, что Вы имеете практический опыт использования языка Дракон для "обмена идеями".
Правильно ли я Вас понял? Если да, не могли бы Вы поделиться своим опытом и рассказать, как именно Вы использовали Дракон? Какие преимущества Вы получили? Какие трудности встретились на Вашем пути?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Понедельник, 12 Май, 2008 16:21 

Зарегистрирован: Среда, 07 Май, 2008 12:25
Сообщения: 15
Владимир Паронджанов писал(а):
Из Вашего первого сообщения как будто следует, что Вы имеете практический опыт использования языка Дракон для "обмена идеями". Правильно ли я Вас понял? Если да, не могли бы Вы поделиться своим опытом и рассказать, как именно Вы использовали Дракон? Какие преимущества Вы получили? Какие трудности встретились на Вашем пути?


Владимир Даниелович, здравствуйте!
Практического опыта применения языка Дракон ещё нет - сейчас идёт внедрение. Когда будут конкретные результаты, обязательно напишу.

Наша команда, www.uidesign.ru, занимается проектированием интерфейсов человек-компьютер. Т.е. по сути мы проектируем сложные системы. У нас очень хорошо получается описывать конкретные состояния системы в виде детальных "чертежей" экранов. На этих же чертежах мы описываем и поведение системы. Поведение описывается текстом и стрелками, указывающими на переход системы из одного состояния в другое (от одного экрана к другому).
Есть предположение, что применение языка Дракон для описания поведения системы перед этапом детального проектирования экранов позволит снизить общие трудозатраты. Это связано с тем, что схемы перерисовать проще, чем перепроектировать экраны. Т.е. более качественная предварительная проработка (схема воспринимается легче текста) снизит количество напрасной работы.
Выделение описания деятельности в отдельный документ, вероятно, облегчит также и последующее внедрение (графический дизайн, html-вёрстка, кодирование) за счёт более наглядного и полного описания спроектированного нами интерфейса.
Конечно же, есть и нюансы. Описание выше дано для пояснения основной идеи.

Большое спасибо TMX за описание применения языка Дракон на всех этапах жизненного цикла разработки устройств на микроконтроллерах!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Понедельник, 23 Июнь, 2008 11:07 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
Есть даже желание (у меня) сделать полноценный компилятор. .. Дракон можно и нужно улучшить, если уж мы хотим сделать его универсальным и стандартным.


Видимо разнонаправленные :) шаги уже сделаны:

1.Привязать отображение декларативной информации можно в граф-схемах
(раскрашенные сети Петри - указывается тип данных, теоретически можно привязать поля типа) http://www.rsdn.ru/article/alg/MRS.xml

2.Преобразование масштаба( зачем это надо - пытались обсудить здесь):
    а. с.124 Рис. 32. Пример операции "подстановка" (здесь и далее - страницы по книге В.Д. Паронджанова)
    б. сворачивание Дракон-схемы в граф-схему (ветка Дракона->переход на граф-схеме)
      рис.136,137 на с.262
      Граф описывает машину состояний (state mashine)
      Дракон-схема описывает машину маршрутов (route mashine ??)
      Применительно к конкретной задаче - это две проекции одной и той же сущности. Насколько эти проекции независимы?
    в. куда дальше сворачивать группу состояний из граф-схемы?
    г. если после "в" попали в Дракон, то далее - п."б" .. и по кругу тыгыдым-тыгыдым-тыгыдым :)

3. Любой язык программирования(из известных), применяемый в качестве единственного командного языка
накладывает ограничения на алгоритмическую часть вследствие:
    а. ограниченности выразительных возможностей языка(где-то есть указатели, где-то нет..)

4. Куда-то ещё надо деть информацию о назначении веток и состояний, теряемую в традиционной системе при написании исходника. Кто-то выносит в комментарии, кто-то нет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 15 Июль, 2008 15:43 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
1.Привязать отображение декларативной информации можно в граф-схемах
Пока отложим сей вопрос...

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

Рэйлвэй Каген писал(а):
Применительно к конкретной задаче - это две проекции одной и той же сущности.
Вот я и говорю - с чего бы?

На самом деле, конечно, можно найти и состояния, и проверку условий. Только проверка условий в Дракон-схеме обычно производится в середине или в конце ветки, где и возникает развилка... Так вот, состояния там и находятся - перед развилками. Перед каждой развилкой, если быть точным. Но такая их трактовка не является полезной для отображения на диаграмме состояний... Это громадная разреженная матрица с узлами, не несущими смысловой нагрузки с точки зрения человека-разработчика.

Рэйлвэй Каген писал(а):
4. Куда-то ещё надо деть информацию о назначении веток и состояний, теряемую в традиционной системе при написании исходника.
Не надо её никуда девать, её надо проектировать! Ведь, по большому счёту, зачем нужны диаграммы состояний? Для того, чтобы разработчик понял, что для него важно, и завёл соответствующие флаги, и отталкивался от этого в дальнейшем.

Ветки Дракона выполняют примерно ту же роль, что процедуры - инкапсуляция ОБЩЕГО кода (технический аспект), а вдобавок к этому - ещё и декомпозицию кода (когнитивный аспект). Причём первое поддаётся формальному анализу, а второе - из области неформального искусства! Посмотрите на диалог Паронджанова с ain'ом, это очень показательно.

Возвращаясь к вопросу о декларативной информации, привязанной к Дракону, мне бы очень хотелось увидеть конкретный пример!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 15 Июль, 2008 15:50 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Alexey_Donskoy писал(а):
А что дальше? Из одного состояния в другие может вести много переходов, и посему требуется (подразумеваемый) интерпретатор состояний, который проверяет УСЛОВИЯ каждого возможного перехода. В конце ветки ничего такого нет, там есть простое продолжение алгоритма (ну, может, ещё точка объединения - в начало очередной ветки может вести много путей). Однако алгоритм в Дракон-схеме детерминирован, и состояний с условиями просто нету!

Этто как так?
Ветка в Драконе может иметь несколько выходов внизу. Развилку по условию со своим адресом дальнейшего перехода в каждом случае! Полноценный стэйт-мачин... :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 15 Июль, 2008 15:55 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Alexey_Donskoy писал(а):
Ветки Дракона выполняют примерно ту же роль, что процедуры - инкапсуляция ОБЩЕГО кода (технический аспект), а вдобавок к этому - ещё и декомпозицию кода (когнитивный аспект). Причём первое поддаётся формальному анализу, а второе - из области неформального искусства!

Для этого просто нужен живой богатый опыт - тогда при хорошей нотации стиль будет выработан идентичный (компактная и продуманная нотация оставляет мало места для незначащих вариаций, т.е. не ставит человека в позу осла перед n равноудалёнными морковками. Лично я в этом убедился на опыте работы с чужими обероновскими исходниками).

А если живого опыта нет - то нужно просто не бояться "перегнуть палку в дисциплине". "Модульности много не бывает" (С) Кто-то из участников этого форума


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ЯВУ, ассемблер и Дракон...
СообщениеДобавлено: Вторник, 15 Июль, 2008 16:07 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Илья Ермаков писал(а):
Ветка в Драконе может иметь несколько выходов внизу. Развилку по условию со своим адресом дальнейшего перехода в каждом случае! Полноценный стэйт-мачин... :-)
Вот, о чём я и говорю. В SD сделан акцент на одно, в Драконе - совершенно на другое. Хотя формально их и можно считать эквивалентными, но в когнитивном аспекте - не получится...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Четверг, 17 Июль, 2008 11:09 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
"..на диаграмме состояний... Это громадная разреженная матрица с узлами, не несущими смысловой нагрузки с точки зрения человека-разработчика"

?? М.б. Вы имели в виду Sequence Diagram?
Вообще-то диаграммы состояний(State Chart) - весьма компактны и информативны.
В противовес им, диаграммы взаимодействия(диаграммы последовательности)
малоприменимы для проектирования мало-мальски сложных систем.
В работе http://is.ifmo.ru/misc/diagrms есть наглядный пример.

Только в данном случае интересуют другие состояния.
Цитата:
"Посмотрите на диалог Паронджанова с ain'ом..."

Владимир Паронджанов ищет "функционально завершенные" состояния будущей системы, подталкивая ain'a к более четким определениям функций системы(перечня действий) и выделению сущностей, с которыми работают эти функции. Может быть я неудачно выразился, пусть более опытные участники меня поправят.

Попробуем препарировать один из результатов http://forum.oberoncore.ru/viewtopic.php?p=17127#p17127
Изображение Изображение Изображение
Прямо по книге В.Д. Паронджанова (ветка Дракона->переход на граф-схеме рис.136,137 на с.262)
Кстати, сворачивание Дракон-схемы в граф-схему может быть выпонено полностью автоматически, с использованием информации из икон "Имя ветки" и "Адрес".
Вложение:
Комментарий к файлу: рис.1
ain.png
ain.png [ 22.78 КБ | Просмотров: 24147 ]

Получили:
1. не определена логика переходов после "Выбор режима"
Цитата:
"..Из одного состояния в другие может вести много переходов, и посему требуется (подразумеваемый) интерпретатор состояний, который проверяет УСЛОВИЯ каждого возможного перехода."

    - на данном уровне проектирования несущественно, как именно
    осуществляется вход в каждый режим. Важно, что разработчик
    предусмотрел различные варианты.
    Реализация - в командной и декларативной части - уровнем ниже.
    Описание перехода - должно быть в терминах логики и времени.
    Как привязать на граф-схеме?
    При восходящем преобразовании в граф-схему - анализировать ветку на предмет
    логических переходов и операторов синхронизации, затем выносить в описание перехода.
    При нисходящем преобразовании из граф-схемы - создавать шаблон ветки с учетом
    указанной на граф-схеме логики переходов.
    В случае сёрфинга по проекту - проверять маршрут на соответствие описанию.

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


.. и свернуть заново:

Вложение:
Комментарий к файлу: рис.2
ain1.png
ain1.png [ 32.94 КБ | Просмотров: 24153 ]


Выводы:
Необходимо, чтобы значимые признаки проектируемой системы не скрывались при любых преобразованиях масштаба. Преобразования масштаба позволяют "на пальцах" почувствовать область видимости и влияние запроектированных признаков системы, оценить их значимость, не отвергая при этом проверенных методик восходящего и нисходящего проектирования.

К слову - Компонентное программирование - разработка "снизу вверх"
Вроде как систематизируется "бардак" ((с)Valery Solovey из указанной темы).
Сочетание восходящего и нисходящего проектирования всё-таки позволяет вытащить дополнительную инфу для проектирования системы.

Предположения:
Часть маршрутной информации верхнего уровня может транслироваться
не только в командные, но и декларативные описания нижележащего уровня.


Цитата:
"Возвращаясь к вопросу о декларативной информации, привязанной к Дракону, мне бы очень хотелось увидеть конкретный пример!"

Давайте зададим этот вопрос Владимиру Даниеловичу,
поскольку доступная на сегодня информация крайне скудна.
(таблицы, списки, вынесенные за пределы Дракон-схемы)


p.s. Не смог найти рисовалку графов вроде применённой в http://is.ifmo.ru/misc/sdvssc.pdf,
поэтому картинки слегка вэк.. Может кому попадалась легкая и фришная??

р.р.s. поправил условия веток на рис.2 + уточнение терминологии


Последний раз редактировалось Рэйлвэй Каген Четверг, 17 Июль, 2008 20:11, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Четверг, 17 Июль, 2008 13:59 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Попробуйте Higres от Новосибирского Института систем информатики им. А.П. Ершова...

http://pco.iis.nsk.su/higres/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Четверг, 17 Июль, 2008 14:02 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Рэйлвэй Каген писал(а):
Вообще-то диаграммы состояний(State Chart) - весьма компактны и информативны.
В противовес им, диаграммы взаимодействия(диаграммы последовательности) малоприменимы для проектирования мало-мальски сложных систем.
Они компактны и информативны как самостоятельная сущность. Но тут ведь пробегало предложение взаимного автоматического перевода Дракон - State Chart. Тогда, если перевести в одну сторону (из диаграммы состояний в Дракон), не будет конкретитки (да ведь это и есть проектирование сверху вниз); а наоборот - тоже теоретически возможно, но диаграмма состояний, поднятая из алгоритма, будет избыточна и нецелесообразна для человека...

Рэйлвэй Каген писал(а):
Владимир Паронджанов ищет "функционально завершенные" состояния будущей системы, подталкивая ain'a к более четким определениям функций системы(перечня действий) и выделению сущностей, с которыми работают эти функции.
Правильно, так и есть! Однако методология получается не очень адекватная, слишком сложная, вроде птолемеевских эпициклов... Можно вместо этого и диаграммы состояний явно применить, а уж переходы отображать и проектировать в Драконе!

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

Рэйлвэй Каген писал(а):
2. не определены действия оператора (вообще не видно, что таковые ожидаются)
Да, это серьёзно...

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

Рэйлвэй Каген писал(а):
p.s. Не смог найти рисовалку графов вроде применённой в http://is.ifmo.ru/misc/sdvssc.pdf, поэтому картинки слегка вэк.. Может кому попадалась легкая и фришная??
как-то попадаются больше CADы фирварные: http://www.progesoft.com/ - аналог автокада, http://www.tflex.ru/ - T-Flex CAD... Но где-то точно видел фришную рисовалку, если найду, сообщу...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Четверг, 17 Июль, 2008 15:24 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Alexey_Donskoy писал(а):
..Но тут ведь пробегало предложение взаимного автоматического перевода Дракон - State Chart.

Ради этого я и налепил графов по ain'овской дракон-схеме.
Alexey_Donskoy писал(а):
Тогда, если перевести в одну сторону (из диаграммы состояний в Дракон), не будет конкретики (да ведь это и есть проектирование сверху вниз)

Конечно не будет. Ведь нисходящее проектирование сводится в конечном итоге к уточнению и детализации на каждом нижележащем уровне. Зато при переходе от граф-схемы к дракон-схеме на каждом нижележащем уровне будут готовые логические рамки и декларативная информация об уже запроектированных сущностях системы.
Alexey_Donskoy писал(а):
..а наоборот - тоже теоретически возможно, но диаграмма состояний, поднятая из алгоритма, будет избыточна и нецелесообразна для человека...

Практически - только что показал на картинках в предыдущем посте. Поднял из дракон-схемы в граф-схему. Избыточности не обнаружил.


Последний раз редактировалось Рэйлвэй Каген Четверг, 17 Июль, 2008 16:12, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Четверг, 17 Июль, 2008 15:49 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Уважаемый Alexey_Donskoy!

По поводу "птолемеевских эпициклов" я ответил Вам здесь
viewtopic.php?p=17129#p17129


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Четверг, 17 Июль, 2008 17:14 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Рэйлвэй Каген писал(а):
Цитата:
"Посмотрите на диалог Паронджанова с ain'ом..."

Владимир Паронджанов ищет "функционально завершенные" состояния будущей системы, подталкивая ain'a к более четким определениям функций системы(перечня действий) и выделению сущностей, с которыми работают эти функции.


Уважаемый Рэйлвэй Каген!

Если говорить по-крупному, я с Вами согласен. Но есть деталь, которая у меня вызывает сомнения. Я имею в виду понятие "состояние" (состояние конечного автомата).

Хочу изложить свое (возможно, ошибочное) мнение по этому вопросу.

Мне кажется, следует различать две трактовки дракон-схемы силуэт.

:!: Первая трактовка ни у кого не вызывает сомнений. Силуэт - это конечный автомат, который может иметь разные состояния. Это часто подчеркивает Илья Ермаков. Много пракических примеров, где демонстрируется плодотворность такой трактовки, дал ТМХ.
viewtopic.php?p=14450#p14450

:!: Вторая трактовка (на которую, как мне кажется, не обратили внимания) - это возможность трактовать силуэт как модификацию метода структуризации программ Ашкрофта-Манны. Об этом я говорил здесь (см. Замечание 3 и замечание 4)
viewtopic.php?p=13427#p13427

Во втором случае задача состоит в том, чтобы дать наиболее ясное и понятное представление структуры (любой) сложной процедурной задачи (алгоритма).

Понятие "алгоритм" шире, чем понятие "автоматный алгоритм".
Понятие "процедурное программирование" шире, чем понятие "автоматное программирование"
Понятие "процедурный язык" шире, чем понятие "автоматный язык".

Я хочу сказать, что дракон - процедурный язык. Мне кажется, когда Илья Ермаков говорит, что Дракон - структурно-автоматный язык, он неоправданно сужает сферу возможного применения языка Дракон.

Перейду к изложению сущности второй трактовки понятия "силуэт".
При второй трактовке понятие "состояние" перестает быть плодотворным. Необходимость в таком понятии отпадает. Ветка при этом трактуется не как "состояние". А как важный структурный (и СМЫСЛОВОЙ) элемент алгоритма (программы).

Примером такой ситуации является задача, которую попытался решить ain.
Если я правильно понимаю ситуацию, ain уже давно написал свою программу. И она успешно работает.
Зачем-же он решил потратить свое драгоценное время на "возню" с Драконом?
По-моему, для того, чтобы получить более ясное представление о своей программе, взглянуть на нее под другим, более выгодным углом зрения.

Вот как я понимаю работу с ain.

А теперь вопрос. Разве ain'у было бы лучше, если бы я стал говорить про конечный автомат и его состояния? Думаю,что нет. Получилось бы неоправданное наукообразие и нагромождение ненужных, избыточных понятий, без которых вполне можно обойтись. И которые ровным счетом ничего не дают для понимания сути дела. А я бы попал в дурацкое положение тех людей, про которых говорят: "Они хочут свою образованность показать".

Поэтому я воспользовался "бритвой Оккама", которая беспощадно отсекает все, без чего можно обойтись. Оккам говорил: "Не умножайте сущности без нужды".

В заключение хочу подчеркнуть: вполне возможно, что я ошибаюсь (это со мной не раз бывало). Кроме того, я сильно рискую, пытаясь говорить о намерениях ain. И о том, какую задачу он перед собой ставит. Я надеюсь, что он сам за себя скажет. И сделает это гораздо лучше меня.


Последний раз редактировалось Владимир Паронджанов Пятница, 18 Июль, 2008 10:59, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Пятница, 18 Июль, 2008 09:37 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Весьма показательно, что удалось вообще без наукообразия переработать вместе с ain его алгоритм.
Можно гарантированно получить хороший результат, зная предметную область и следуя только простым правилам работы с изображениями - всё это без попутного изучения пары книг по структурному и ОО-программированию или десятка теорем и полусотни особенностей преобразования графов конечных автоматов. Никто не запрещает освоить перечисленный или более широкий набор знаний по мере надобности и защищать построенную систему с привлечением всего доступного наукообразия(причем результат опять-таки будет положительным).

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

Связи между ветками силуэта в Дракон-схеме являются невизуальными.

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

Но в целом, это только половина работы, причем основа сделана В.Д.Паронджановым задолго до этого обсуждения:
    восходящее дракон-схема -> граф-схема (ветка силуэта -> переход; с сокращением избыточности)

Для успешного "тыгыдым-тыгыдым-тыгыдым по кругу" нужны преобразования :
    нисходящее граф-схема -> дракон-схема (переход -> ветка силуэта; с созданием шаблонов)
    нисходящее дракон-схема -> граф-схема (с созданием шаблонов)
    восходящее граф-схема -> дракон-схема (с сокращением избыточности)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Пятница, 18 Июль, 2008 11:06 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
Рэйлвэй Каген писал(а):
...Насколько удобнее(эргономичнее) проектировать логику работы системы в таком ["свёрнутый" алгоритм] представлении? Для меня - удобно, но не факт, что кому-то ещё понравится. Привлекает возможность введения неструктурированной информации в произвольном виде. Для начального этапа больших проектов это достаточно важно, поскольку на "высоком уровне трудно отделить главное от второстепенного, трудно даже заставить себя это проделать"((с)Илья Ермаков)...
Какая информация в каком виде представляется - неважно. Занимаясь большими проектами, Вы сталкиваетесь с описанными Ильёй проблемами. Автоматическая трансляция здесь не поможет. А если до неё дошло, то описанное Ильёй уже позади.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Пятница, 18 Июль, 2008 11:48 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Рэйлвэй Каген писал(а):
Весьма показательно, что удалось вообще без наукообразия переработать вместе с ain его алгоритм.
Можно гарантированно получить хороший результат, зная предметную область и следуя только простым правилам работы с изображениями - всё это без попутного изучения пары книг по структурному и ОО-программированию или десятка теорем и полусотни особенностей преобразования графов конечных автоматов. Никто не запрещает освоить перечисленный или более широкий набор знаний по мере надобности и защищать построенную систему с привлечением всего доступного наукообразия(причем результат опять-таки будет положительным).


Согласен на 100%. Привлечение всего доступного научного аппарата безусловно является положительным и крайне желательным моментом. Вместе с тем в жизни существует реальная проблема, которую Джеймс Мартин обозначил как "Прикладное программирование без программистов" (Application Development without Programmers). Это очень сложная проблема. И ее тоже надо решать. Причем решать эффективно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ещё отзывы о Драконе
СообщениеДобавлено: Понедельник, 26 Январь, 2009 10:01 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Андрей Федяев писал(а):
Есть ли возможность пустить в массы то, что применяется в ракетно-космической отрасли?

Не во всей отрасли, а в НПЦ им. Пилюгина.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.

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


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

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


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

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