DRAKON.SU

Текущее время: Вторник, 03 Август, 2021 11:19

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




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Среда, 05 Октябрь, 2011 17:25 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5214
Откуда: Москва
Артемий Чекушин прислал мне письмо
Цитата:
Здравствуйте, Владимир Данилович!

Встретил Вашу книгу "Дружелюбные алгоритмы, понятные каждому" в "Библио-глобусе" и сейчас, с интересом, заканчиваю ее чтение.

Очень понравилась логическая структура языка ДРАКОН, в сравнении с другими языками графического представления алгоритма, такими как разработка Microsoft для Robotics Studio - VPL, или языком встроенным в LabView и др. и хотя вышеназванные языки являются специализированными языками для своих областей, Ваш заметно выигрывает в представлении структуры алгоритма, правила языка более строгие и логичные.

Очень бы хотелось видеть среду разработки, в которой использовался бы ДРАКОН, или гибридный язык, так как зачастую он является очень хорошим средством для быстрой разработки или прототипирования алгоритма программы, и поэтому хотелось бы сразу видеть результат работы или уже законченное вычисление, чтобы не записывать алгоритм на другом языке, а в дополнение к этому очень удобной была бы генерация кода из языка ДРАКОН в другой язык.

Сейчас существует редактор ДРАКОН языка, очень удобное средство, и для него было бы замечательно иметь средство кодогенерации на другом языке, например Компонентном Паскале.

Мне было бы самому интересно участвовать в разработке такой системы, если бы были единомышленники.

Я видел работу Романченко Я.М. в этом направлении - генерация кода в Оберон, но она кажется остановилась.

Может быть было бы лучше иметь в качестве подсистемы редактор ДРАКОНА в системе BlackBox, чтобы иметь возможность "прозрачно" обмениваться кодом с Компонентным Паскалем, а так же легкой генерации модулей на нем из ДРАКОНА.

Сейчас повсеместно используется Объектно-ориентированное программирование или компонентно-ориентированное программирование, конечно это не единственные интересные парадигмы для разработки больших программ, но именно они позволяют работать большим программам и повторно использовать большую часть разработанного кода повторно, без внесения изменений, и было бы очень интересно иметь графический язык для составления ООП программ.

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

Не думали ли Вы раньше, чтобы создать такой язык?


В качестве примера иконок прикрепляю рисунок.


С уважением Артемий Чекушин


Я послал Артемию мейл с приглашением на наш форум


Последний раз редактировалось Владимир Паронджанов Среда, 05 Октябрь, 2011 17:58, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Тема Артемия Чекушина
СообщениеДобавлено: Среда, 05 Октябрь, 2011 17:34 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Паронджанов писал(а):
Артемий Чекушин прислал мне письмо
Цитата:
...
В качестве примера иконок прикрепляю рисунок.
...

А рисунок можно увидеть?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 05 Октябрь, 2011 17:39 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5214
Откуда: Москва
Ильченко Эдуард писал(а):
А рисунок можно увидеть?
Вложение:
ГрафическоеООП.png
ГрафическоеООП.png [ 13.08 КБ | Просмотров: 11369 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 05 Октябрь, 2011 18:00 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Не очень понятно из рисунка, что хотел изобразить Артемий.
В чём преимущества иконки-класса?
Цитата:
генерация кода в Оберон, но она кажется остановилась
что значит "остановилась"? Концепция есть. Рабочий прототип есть. Единомышленников нет. Нормального редактора нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 05 Октябрь, 2011 18:15 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Ярослав Романченко писал(а):
Единомышленников нет. Нормального редактора нет.
Что требуется от единомышленников?
Что нужно от редактора, что бы быть нормальным?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Октябрь, 2011 08:44 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Впервые о такой вещи задумался на форуме, кажется, dvuugl: viewtopic.php?f=62&t=1787#p33650 . Далее делал попытку (на базе АТ-алфавита) Р. Самойлов: viewtopic.php?p=51962#p52044 . Здесь вижу попытку отталкиваться от диаграммы классов юмля. Но насколько она соответствует смыслу? Нужна формальная модель ООП-программы. Её и нужно визуализировать.

С КП всё проще - язык очень многое отражает, ибо компонентная парадигма предполагает минимум расхождений между статикой и динамикой. Поэтому и возможно построить графит-КП преимущественно по стандарту самого КП. Что и стоит за этой частью предложения А. Чекушина. В основном работа завершена, результаты отражены пока здесь: http://drakonografika.narod.ru/L2/index ... pril2.html . А концепция здесь: viewtopic.php?f=62&t=2527#p60855 .
    Если снова возникнут вопросы насчёт оформления страниц описания - замечания учёл в новом дизайне, но насчёт изменения существующих страниц - не всё сразу... :wink:

Если послушать наиболее ярых противников формально-эргономичнеой визуализации на К-терре, скажем - то такой модели для ООП и быть не может. Но у Непейводы есть кое-какие соображения на эту тему. А кое-что ещё, IMHO, можно найти в этой книге: viewtopic.php?f=75&t=3586#p66034 . Имеется в виду пп 4.3, 4.4 (в выдержку не вошло, но книга есть в продаже).
У кого есть желание - разбирайтесь, как визуализировать эту модель (а м.б. с ней надо ещё сделать какие-то преобразования и/или интерпретировать правильно для этих целей).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Октябрь, 2011 10:50 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Геннадий Тышов писал(а):
Что требуется от единомышленников?
Это понятно из самого слова... Мыслить приблизительно в одном направлении.
Геннадий Тышов писал(а):
Что нужно от редактора, что бы быть нормальным?
Базироваться на строгой концепции а не обрастать свистелками и перделками на основании сиюминутных позывов. Конкретных предложений по поводу концепции редактора было полным-полно в рамках данного форума.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Октябрь, 2011 17:33 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Ярослав,
вы можете концентрировано выразить свою мысль и свою концепцию редактора?

На форуме во всем наблюдается разнобой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 07 Октябрь, 2011 09:45 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ну, в общем разумные концепции таковы:

1) Построить редактор для базиса из языка, изоморфного существующему прогязыку (напр., КП) и языков схематизации, какие есть (КогниСтиль+ГРАФ; имеем в виду, что МОЛНИЯ - подмножество первого, ГНОМ - второго), используя для невнутрисхемных связей в модельном документе (базе документов) исключительно гиперссылки.

2) Создать новый прогязык и/или концепцию схематизации (базы документов и её представления), потом изоморфное семейство визуальных языков и построить РТ под них

3) Создать системную теорию формализации и представления отчуждаемых знаний, потом языки, и потом уже построить РТ.

Фактически соответствуют уровням сложности, на которых решаем задачу моделирования/формализации и её поддержки.

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

Второй вариант "через и" здесь представлен концепцией структурного редактора. Схематизация базы документов решается через показ зависимостей программных компонентов; как будет решаться для непрограммной части - пока неясно (Валерий высказывал некоторые идеи). Я ограничиваюсь концепцией схематизации через лист-силуэты.

Третий вариант представлен сторонниками предметных языков и семантического моделирования - в сущности, общей теории деятельности и её предметов. Разумеется, это в первую очередь alexus. Дело на перспективу.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 09 Октябрь, 2011 09:24 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ярослав Романченко писал(а):
...
Геннадий Тышов писал(а):
Что нужно от редактора, что бы быть нормальным?
Базироваться на строгой концепции а не обрастать...
Причём концепция подразумевает использование базового минимума знаний о формализации. На которые пришлось указать здесь (в конце поста).
Справедливости ради - его неиспользование характерно и для оголтелых противников техноязыка и метода. Так, в претензии, упомянутой в этом посте, в сущности, главное - это та же "слеплённость" предлагаемой блок-схемы. Которую, по утверждению корреспондента, Паронджанов (или кто-то другой) не показал ему, как переписать на техноязыке. Или это инсинуация и перевод в дракон-схему существует?...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Октябрь, 2011 20:51 

Зарегистрирован: Среда, 06 Май, 2009 21:00
Сообщения: 32
Техническое предложение - может, на первых порах, достаточно ограничится действиями над объектами?
Объект содержит поля и методы их обработки, которые и надо изобразить на дракон-схеме.
Для действий над полями удобно использовать иконку "полка" -вверху имя объекта, внизу поле.
Для вызова методов можно разделить иконку "действие" на две части. В левой - имя объекта в правой - имя метода.
При этом, возможно, декомпозицию на классы можно сделать автоматически, собирая из иконок имена объектов, полей и методов.
Слегка модифицированный пример из книги Владимира Даниеловича на схеме.
Что видно из схемы:

Имеем объект класса - тарелка
поле - состояние=норма, взрыв, авария.
методы - включить телепорт, отключить гравитацию, выход из астрала

Класс двигатель, экземпляры класса - левый двигатель, правый двигатель.
метод - проверить
поле -состояние=норма, не работает
и т.д и т.п. :)

Цель - сохранить наглядность, и в то же время, обеспечить однозначность трансляции дракон схемы в код.


Вложения:
Новый_01_1.png
Новый_01_1.png [ 18.68 КБ | Просмотров: 11161 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Октябрь, 2011 21:12 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
and007
Имя класса и/или объекта пишем в идентификаторе иконы.
Действия с полями и действия методов описываем в тексте иконы.

Таким образом в ИС Дракон имеется все для работы с объектами (классами).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Октябрь, 2011 06:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ну, техническое предложение подразумевает расчётно-логическую часть. Т.е. обоснование, как это получается. Иначе это называется идеей/гипотезой. Это не умаляет возможной ценности сказанного - просто уточняет место. :)
А здесь надо смотреть, чтобы не вышло очередного издания "карго-культа". Т.е. подмены образования конкретной программы из классовой структуры в рантайме собиранием имён из иконок. М.б. это и не так - но бремя доказывания лежит на утверждающих... :wink: Наверное, что-то можно почерпнуть для обоснования у того же Бабичева... или для отказа от этой идеи и выдвижения новой... :D


Последний раз редактировалось Владислав Жаринов Суббота, 03 Декабрь, 2011 06:07, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Октябрь, 2011 09:12 

Зарегистрирован: Пятница, 22 Июль, 2011 08:11
Сообщения: 3
and007 писал(а):
Техническое предложение - может, на первых порах, достаточно ограничится действиями над объектами?
Объект содержит поля и методы их обработки, которые и надо изобразить на дракон-схеме.
Для действий над полями удобно использовать иконку "полка" -вверху имя объекта, внизу поле.
Для вызова методов можно разделить иконку "действие" на две части. В левой - имя объекта в правой - имя метода.
При этом, возможно, декомпозицию на классы можно сделать автоматически, собирая из иконок имена объектов, полей и методов...

Цель - сохранить наглядность, и в то же время, обеспечить однозначность трансляции дракон схемы в код.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Октябрь, 2011 09:24 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Интересно. Для класса или для модуля? Как этот элемент должен входить в структуру визуальной записи программы? Как представляется структура класса, а как - КП-модуля? Как показывается реализация наследования?
Или всё-таки речь о Мейеровском понимании структурирования программы - на модули-классы, как обсуждалось здесь?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Октябрь, 2011 10:58 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5214
Откуда: Москва
hansel писал(а):
Я предложил отдельную иконку для класса или модуля для того чтобы сохранить целостность в визуальном представлении для класса(модуля), а так же чтобы при реализации этой идеи в редакторе была возможность при желании "заглянуть" внутрь класса увидеть его полную структуру и более простого его редактирования, а в дальнейшем иметь возможность реализовать наследование, как мне кажется для этого иметь отдельную иконку класса(метода) удобнее.


Уважаемый hansel!

Пожалуйста, нарисуйте и покажите здесь:

1. вашу "отдельную иконку для класса или модуля "

2. приведите несколько примеров заполнения вашей иконки текстом

3. дайте необходимые пояснения (с учетом вопросов Владислава Жаринова)
___________________________________

Ваше предложение очень интересно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Октябрь, 2011 15:54 

Зарегистрирован: Пятница, 22 Июль, 2011 08:11
Сообщения: 3
Владимир Паронджанов писал(а):
hansel писал(а):
Я предложил отдельную иконку для класса или модуля для того чтобы сохранить целостность в визуальном представлении для класса(модуля), а так же чтобы при реализации этой идеи в редакторе была возможность при желании "заглянуть" внутрь класса увидеть его полную структуру и более простого его редактирования, а в дальнейшем иметь возможность реализовать наследование, как мне кажется для этого иметь отдельную иконку класса(метода) удобнее.


Уважаемый hansel!

Пожалуйста, нарисуйте и покажите здесь:

1. вашу "отдельную иконку для класса или модуля "

2. приведите несколько примеров заполнения вашей иконки текстом

3. дайте необходимые пояснения (с учетом вопросов Владислава Жаринова)
___________________________________

Ваше предложение очень интересно.



Извиняюсь, что мог ввести в заблуждение, с моего письма Вам началась эта ветка в форуме. hansel - это мой псевдоним здесь, который я ввел по неосмотрительности, когда регистрировался

Артемий Чекушин


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Октябрь, 2011 23:54 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
and007 писал(а):
Объект содержит поля и методы их обработки, которые и надо изобразить на дракон-схеме.

Можно ещё такие варианты предложить ...
Вложение:
pyA05.png
pyA05.png [ 12.62 КБ | Просмотров: 10994 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Октябрь, 2011 19:17 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Всё можно... :) А как это соотносится с "классообразованием" в объектной программе?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Ноябрь, 2011 10:39 

Зарегистрирован: Пятница, 22 Июль, 2011 08:11
Сообщения: 3
Владислав Жаринов писал(а):
Всё можно... :) А как это соотносится с "классообразованием" в объектной программе?..



Я, видимо, очень вольно оперирую терминами из ООП :-)
Может быть не имеет смысла использовать классы для визуального представления объекта вообще. Наверное для этого гораздо ближе будет модель принятая в модульном программирование, которое и используется в Компонентном Паскале или может быть прототипная модель, такая, как используется в JavaScript(ECMAScript), так как в этих случаях используются менее абстрактные сущности, чем класс.


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

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


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

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


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

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