OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 13:37

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




Начать новую тему Ответить на тему  [ Сообщений: 50 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 26 Июль, 2012 19:13 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Да, конечно, традиционная структура документа - как иерархически нумерованных докэлементов - не просто так и она будет актуальна. Схематически её можно поддержать, скажем, вьюшкой по такому принципу, как говорилось здесь: viewtopic.php?p=64343#p64343. Разбираться должно помочь... да и в реализации те же силуэты, только положенные набок... :)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Июль, 2012 16:17 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Дмитрий_ВБ в viewtopic.php?p=73601#p73601 писал(а):
Ну, пока у меня самого в голове все еще должным образом не устаканилось, поэтому ответить на все
вопросы я не смогу.
...
ссылки на другие документы - сейчас есть ссылки на htm-файлы, хотя возможно и достаточно корявые:
---------------- из файла конфигурации ------------------------
; ссылка на записи htm-файлов (здесь N модуля - это N htm-файла):
; _>2#10 - это ссылка на запись c именем "i.10" 2-го htm-файла
-------------

Возможно, это даст что-то: http://www.rsdn.ru/forum/philosophy/483 ... ?tree=tree (ну и некоторые связанные посты там же).

Дмитрий_ВБ в viewtopic.php?p=73601#p73601 писал(а):
...
"4) А что, если реализовать полноценное двумерное структурирование кода на базе ЛСП? И тогда не делать отдельно полуторамерный текст ..."

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 30 Июль, 2012 16:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Да, вот ещё.
Дмитрий_ВБ в viewtopic.php?p=73590#p73590 писал(а):
...
для псевдокода по умолчанию
переход к следующей по порядку ветке мы опускаем, а во внутреннем формате
программы такие переходы должны быть. Поэтому в примере для ЛСП нужно
расставить

П Вслед НД

для веток: 1, 4, 5, 6, 7, 11, 12, 13, 14, 15
...
Что это за переходы и почему они нужны?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 30 Июль, 2012 16:49 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
"Что это за переходы и почему они нужны?"

Для попадания в следующую по порядку ветку в следующем проходе цикла-силуэта


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Июль, 2012 13:10 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 04 Август, 2012 10:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Владислав Жаринов в viewtopic.php?p=73602#p73602 писал(а):
Да, конечно, традиционная структура документа - как иерархически нумерованных докэлементов - не просто так и она будет актуальна.
...
Кстати, она актуальна и при эскизном описании процессов - достаточно посмотреть на эту задачу: viewtopic.php?p=66824#p66824. И тут видно, что надо решать вопрос с индексацией элементов схемы в аспекте, обсуждавшемся здесь: viewtopic.php?p=72208#p72208.
Владислав Жаринов в viewtopic.php?p=73602#p73602 писал(а):
...
Как проще редактировать неграфическую форму структурированного описания - ... - только тогда придётся писать ключевые маршрутные слова - графика-то не используется.
Отсюда и необходимость поддержать и для неграфики "исчисление вложением" - т.е., как и Прохоренко указывает, вставлять целые конструкции.

...
... и тогда уж реализовать и то, что называю "графит-примечаниями" и что Сергей определял здесь: viewtopic.php?p=57545#p57545.
Т.е. каждой структурной скобке (заменяющей ключевые слова-указатели маршрутов) соответствует комментарий - как и каждому оператору. При "своей" скобке он и отображается. Интендация текста заменяется вложенностью скобок; текст располагается одномерно - в колонку строк. Это формат вьюшки исхтекста совместно с комментариями (в отличие от вида только исхтекста как "схемы со снятой графикой", где и скобки двумерны, и каждой оси порядка - своя колонка).
Такие "атомарно-релятивные" комменты - прежде всего для утверждений о конструкциях, ограниченных скобками. Ну и для просто записей, включая ссылки на разные места в документах среды и во внешних. Для начала (дабы не усложнять реализацию) внутри среды ссылки - на те самые индексы, вовне - как уже говорил, на закладки в каком-то кроссплатформенном формате.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 16 Август, 2012 11:31 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Владислав Жаринов писал(а):
...
Это формат вьюшки исхтекста совместно с комментариями (в отличие от вида только исхтекста как "схемы со снятой графикой", где и скобки двумерны, и каждой оси порядка - своя колонка).
...
Что понимаю под двумерной (физически) текстовой записью - теперь можно видеть в этом посте на примере ветвления. Для цикла будет, разумеется, аналогично.

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

Вот такую вьюшку хотелось бы видеть...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Март, 2013 17:58 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Таблица-силуэт с горизонтальной раскладной действий для языка ДАЛВЯЗ 2

(пока не реализовано, выкладываю как материал для обсуждения)

Логика работы остается той же:
- во главе угла ЛСП (логическая структура процедуры), набор действий
которой (подробнее см. тему "AB_VJAZ и DAL_VJAZ") опирается на постулат
структурного программирования:

для выполнения некоторой последовательности действий требуется
следующий минимальный набор действий:

1) простое действие (присваивание, вызов процедуры);
2) ветвление (сложное условие);
3) цикл.

При горизонтальной раскладке действий действия выполняются
слева направо, ветка ДА условия уходит вправо, а ветка НЕТ - вверх.
Т.е. условие горизонтальной раскладки - это повернутое на 90 градусов
против часовой стрелки условие вертикальной раскладки, для которого
ДА - вниз, НЕТ - вправо. Для условия цикла ветка ДА означает окончание
цикла.

Базовые элементы ЛСП для горизонтальной раскладки выглядят
следующим образом:
Вложение:
ris1.JPG
ris1.JPG [ 19.59 КБ | Просмотров: 12485 ]

При необходимости задания в программе сложных ветвлений необходимо
воспользоваться логикой [цикла-]силуэта.
Вложение:
ris2.JPG
ris2.JPG [ 20.9 КБ | Просмотров: 12485 ]

Если веток много, используем таблицу-силуэт.
При этом для блоков Начало, Цикл-Силуэт, Условие Цикла-Силуэта и Конец
будем использовать вертикальную раскладку.
Вложение:
ris3.JPG
ris3.JPG [ 55.15 КБ | Просмотров: 12485 ]

Параллельные действия для горизонтальной раскладки

1) Алгоритм запуска параллельных действий, который может быть
преобразован в исходный код
Вложение:
ris4.JPG
ris4.JPG [ 19.83 КБ | Просмотров: 12485 ]

2) Нестрогое описание параллельных действий с помощью таблицы-силуэта
Вложение:
ris5.JPG
ris5.JPG [ 568.85 КБ | Просмотров: 12485 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Март, 2013 18:21 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 04 Март, 2013 18:08 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот, кстати, пример на то, что имел в виду:
Геннадий Тышов писал(а):
Геннадий Тышов писал(а):
Возьмите ИС Дракон, составьте схему с имеющими у Вас вопросами, рассортируйте по приоритетам и последовательно их решайте, новые вопросу туда же добавляйте, общие вопросы разделите на частные.
Отведите в Силуэте различные ветки для вопросов находящихся на различных этапах решения вопросов. Перемещайте иконы по мере прохождения этапов решения.

В ИС Дракон имеется возможность ставить галочку рядом с иконой.
Ставьте галочку у икон с решенными вопросами и Вы будите видеть соотношение между общим количеством вопросов и количеством вопросов ожидающих решение.

Занимайтесь решением только одного вопроса, остальные не будут Вас напрягать, а будут существовать только в Дракон-схемах. ...
- в том смысле, что если сочинитель делает "последовательный алгоритм" по Закревскому из работ, которые м.б. переупорядочены, то у него всё равно никуда не девается необходимость координации. И в результате такой алгоритм превращается в "эвроритм". А АРМ, получается, используется в роли доски у диспетчера... :wink: тогда как могло бы "поддерживать принятие решений"...

Вы вроде как хотите описать принципы координации, если я верно понял. Чтобы переложить на среду (точнее, на записанный в ДАЛВЯЗ-проекте код) функции выбора работ к активации/откладыванию/снятию. Ну, понятно, в ограничениях теории расписаний, как популярно у Потопахина: viewtopic.php?p=78120#p78120.
Но штука в том, что если сочинитель и опишет все правила запуска хоть и в виде текста предлагаемых схем, ему это всё равно не поможет "развернуть в бизнес-процессы" сколь-нибудь развитые структуры "вопросов, находящихся на различных этапах решения, перемещаемых по мере прохождения этапов"... И вот хотелось бы от среды на этом коде:
    * проявления "неявного поведения/зависимостей, которое в реальном коде образуется немыслимыми сочетаниями сценариев";
    * учёта вещей вроде описанных тут: viewtopic.php?p=74833#p74833.
Конечно, это м.б. сделано по-разному. В частности, ограничиваясь тем, что реализуется в ДАЛВЯЗ, можно просто экспортировать код для внешнего анализа вроде такого: viewtopic.php?p=74705#p74705 и импортировать обратно.

Кстати, "рисунки из книги" тоже в тему... ибо взаимодействие м.б. организовано как раз через рандеву...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Март, 2013 09:59 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Не, Владислав, у меня все гораздо проще.

Никаких целей по выработке планов координации работ проекта или семантического анализа
проекта на предмет выяснения внутренних логических несоответствий и ошибок проекта я
перед собой не ставлю.

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

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

Т.к. ЛСП является логическим инвариантом, то для нее имеются 3 формы отображения (см. рис.):
- линейная вертикальная раскладка;
- линейная горизонтальная раскладка;
- вертиально-горизонтальная раскладка.
Вложение:
ris11.JPG
ris11.JPG [ 33.88 КБ | Просмотров: 12434 ]


Ну и остается вопрос эргономичного отображения визуальной схемы.
Владимир Даниелович этот лозунг провозгласил,
и 3 шага в этом направлении:

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

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


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

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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 05 Март, 2013 12:49 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Я конечно не спец по эргономике, поэтому мой ответ, возможно будет поверхностным,
но есть следующие группы вопросов:

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

В качестве примера приведу вопросы, поднятые мной в теме "Просто о силуэте", которые
остались без ответа:

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

2) какая степень детализации алгоритма является оптимальной для визуальной схемы ?

3) должна ли визуальная схема по высоте обязательно целиком помещаться в окне просмотра ?"

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

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

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

5. Формы блоков схемы были выбраны волевым решением автора языка, и некоторые из них
не являются оптимальными, например из замечаний на формуме:
- "гробики" условий;
- блок комментария лучше смотрится в UML

Вроде это все основные замечания по визуальным вопросам.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Март, 2013 10:09 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Все сказанное выше по поводу языка ДРАКОН вовсе не значит, что он никуда не годится.
Он работает - в своей области, не хуже других аналогичных систем.

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

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

На сайте videoecology.com в разделе
Книги и фильм
Видеоэкология
Текст - введение, заключение, содержание
читаем:
"Актуальность проблемы видеоэкологии еще и в том, что наука
до сих пор не разработала нормативные документы по формированию
визуальной среды, нет требований по допустимым отклонениям,
в частности по допустимым размерам гомогенных и агрессивных полей".
На мой взгляд мнение доктора биологических наук Василия Антоновича Филина - это достаточно
авторитетный источник.

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

Мои предложения уже во многом сформулированы в описании алгоритмического языка ДАЛВЯЗ 2
и вкратце сводятся к следующему:
- в качестве логической основы: постулат структурного программирования (просто и проверено
временем) плюс логика цикла-силуэта для обработки сложных логических переходов;
- в качестве визуальной основы: схема с запретом на пересечение линий и пространственной
структурой, задаваемой визуально-логической конструцией силуэт (таблица-силуэт)
- у пользователя должна быть возможность выбирать раскладку схемы (подробнее см. в моем
сообщении выше):
линейная горизонтальная, линейная вертикальная или вертикально-горизонтальная;
- в качестве формата данных: текстовый файл, содержащий исходный код (или псевдокод),
для которого будет отображаться схема; исходный код содержит не только процедуры, но и
описание данных проекта; исходный код разбивается на записи, котрые могут ссылаться
друг на друга, на исхдный код других модулей проекта и на внешние htm-файлы документации;
- должна быть предусмотрена возможность вставки в блоки схемы как поясняющих значков,
так и полноценных изображений;
- пользователь должен иметь простую возможность задания цветового оформления схемы
и выбора используемых в ней шрифтов путем редактирования файлов стилей схемы.

Вот как с моей точки зрения выглядят МИНИМАЛЬНЫЕ требования к универсальному средству
алгоритмизации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Март, 2013 10:18 
Модератор
Аватара пользователя

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


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

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

Дракон одновременно и понятен им, и структурирует их "неформатированное математикой" мышление. Чёткие и понятные "это нельзя, а нужно вот так", исключающие разгул неупорядоченной фантазии гуманитария, начавшего рисовать :)

Аргумент "нужны красивости, достаточно ли гуманитариям строгих схем" - не согласен. Привычки "клипового" мышления нужно ограничивать, а не потакать им.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Март, 2013 10:35 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Цитата:
Илья Ермаков пишет:
Аргумент "но и новичков, для которых главное - сделать побыстрее и чтобы сразу заработало." - тоже не согласен. Я такого рода аргумент всегда называю "Бейсик-аргументом". Именно из-за этого ошибочного мнения (потакания желанию новичка пару раз "тык-мыкнуть", не думая и не вникая, и чтобы был результат) создавались Бейсик-подобные языки и ошибочно они считаются "хорошими для начинающих", хотя, на самом деле, намертво тормозят развитие их ума в правильном направлении...


Даже если в основе такого "новоявленного Бейсика" будет лежать алгоритмическая логика КП
(а если брать текстовый формат - то и сам КП) ?
Ну а графические висюльки - когда ребенок взрослеет, он отказывается от погремушек.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Март, 2013 12:33 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Смотря что Вы вкладывали в "побыстрее бы заработало".
Последнее Ваше высказывание ясности не добавляет....
Что именно Вы считаете препятствием для новичком на пути к "побыстрее бы заработало"?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Март, 2013 13:24 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Тут все зависит от того, для чего используется среда.
Если гуманитарий рисует в ней какой-нибудь алгоритм, то "побыстрее бы заработало"
означает преодоление им порога уверенного пользователя средой плюс эргономичность
средств создания алгоритма. На выходе в текстовом формате будем иметь псевдокод
алгоритма и, конечно схему алгоритма.
А если мы имеем в виду студента, обучающегося программированию, то на выходе будут
алгоритм процедуры и исходный код, назначение каждой строки которого студент по идее должен
бы ясно понимать, даже если маршрутные операторы условий и циклов будут генериться автоматиески.
Ведь сами условия и текст действий все-равно придется вводить вручную (тут же не
предполагается такого автоматизма, как у Валерия Лаптева - вот он даже и текстовый редактор в
процессе обучения программированию требует запретить). Ну а побыстрее заработало - это чтобы
программа поыстрее заработала правильно.
Понятно, что студент и преподаватель вкладывают в эту фразу разный смысл, ну так я ведь и
не преподаватель.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 06 Март, 2013 14:55 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Понял Ваши мысли.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Август, 2013 18:41 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Схемы данных в ДАЛВЯЗ 2

В общем случае дерево описания программы в ДАЛВЯЗ 2 выглядит так:

программа такая-то
...
n. модуль такой-то
...
n.m. запись такая-то, это либо текстовая запись,
либо схема действий,
либо схема данных.

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

Рассмотрим простой пример из Википедии

JSON — Википедия.htm :
"JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными,
основанный на JavaScript
Код:
JSON-представление объекта, описывающего человека

{
   "firstName": "Иван",
   "lastName": "Иванов",
   "address": {
       "streetAddress": "Московское ш., 101, кв.101",
       "city": "Ленинград",
       "postalCode": 101101
   },
   "phoneNumbers": [
       "812 123-1234",
       "916 123-4567"
   ]
}

На языке XML подобная структура выглядела бы примерно так:

<person>
  <firstName>Иван</firstName>
  <lastName>Иванов</lastName>
  <address>
    <streetAddress>Московское ш., 101, кв.101</streetAddress>
    <city>Ленинград</city>
    <postalCode>101101</postalCode>
  </address>
  <phoneNumbers>
    <phoneNumber>812 123-1234</phoneNumber>
    <phoneNumber>916 123-4567</phoneNumber>
  </phoneNumbers>
</person>"

А вот как выглядит структура из Википедии в записи псевдокодом:

СХЕМА.10. Учетная карточка покупателя Иванова
   * если firstName [-]
   Имя:
      * Иван
   * иначе если lastName [-]
   Фамилия:
      * Иванов
   * иначе если address [-]
   Адрес:
      * если streetAddress [-]
      Улица:
         * Московское ш., 101, кв.101
      * иначе если city [-]
      Город:
         * Ленинград
      * иначе если  postalCode [-]
      Почтовый индекс:
         * 101101
      * конец
   * иначе если phoneNumbers [-]
   Телефоны:
      * 812 123-1234
      * 916 123-4567
   * конец
   * выход
* КОНЕЦ СХЕМЫ

По аналогии с приведенными примерами для JSON и XML видно, что
в псевдокоде условие задает имя поля структуры, а действие
задает значение для этого поля.

Программа dal2html для приведенного псевдокода построит следующую
схему:
Вложение:
10.jpg
10.jpg [ 39.65 КБ | Просмотров: 12081 ]

Примерно так же можно описывать и отображать структуру таблиц
или обобщенную структуру данных для объектов разных типов,
имеющих как общие поля данных, так и уникальные для каждого
типа объекта.


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

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


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

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


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

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