OberonCore https://forum.oberoncore.ru/ |
|
КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема https://forum.oberoncore.ru/viewtopic.php?f=121&t=3989 |
Страница 2 из 3 |
Автор: | Владислав Жаринов [ Четверг, 26 Июль, 2012 19:13 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Да, конечно, традиционная структура документа - как иерархически нумерованных докэлементов - не просто так и она будет актуальна. Схематически её можно поддержать, скажем, вьюшкой по такому принципу, как говорилось здесь: viewtopic.php?p=64343#p64343. Разбираться должно помочь... да и в реализации те же силуэты, только положенные набок... Как проще редактировать неграфическую форму структурированного описания - я не зря упомянул о тех же таблицах. Именно путём их заполнения - только тогда придётся писать ключевые маршрутные слова - графика-то не используется. Отсюда и необходимость поддержать и для неграфики "исчисление вложением" - т.е., как и Прохоренко указывает, вставлять целые конструкции. В общем, не д.б. никакой разницы между способом построения с графом и без него - только форма представления разная. Кстати, и алгоритмы редактирования в основе своей унифицируются (только компоновочная часть может отличаться). |
Автор: | Владислав Жаринов [ Воскресенье, 29 Июль, 2012 16:17 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Дмитрий_ВБ в 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 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Да, вот ещё. Дмитрий_ВБ в viewtopic.php?p=73590#p73590 писал(а): ... Что это за переходы и почему они нужны?
для псевдокода по умолчанию переход к следующей по порядку ветке мы опускаем, а во внутреннем формате программы такие переходы должны быть. Поэтому в примере для ЛСП нужно расставить П Вслед НД для веток: 1, 4, 5, 6, 7, 11, 12, 13, 14, 15 ... |
Автор: | Дмитрий_ВБ [ Понедельник, 30 Июль, 2012 16:49 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
"Что это за переходы и почему они нужны?" Для попадания в следующую по порядку ветку в следующем проходе цикла-силуэта |
Автор: | Владислав Жаринов [ Вторник, 31 Июль, 2012 13:10 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
В общем, для связки текстов веток в последовательность - то, что в языках без goto делается просто стыковкой соответствующих текстов?.. |
Автор: | Владислав Жаринов [ Суббота, 04 Август, 2012 10:38 ] |
Заголовок сообщения: | Формальный и неформальный текст -> схема и обратно |
Владислав Жаринов в 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 ] |
Заголовок сообщения: | Re: Формальный и неформальный текст -> схема и обратно |
Владислав Жаринов писал(а): ... Что понимаю под двумерной (физически) текстовой записью - теперь можно видеть в этом посте на примере ветвления. Для цикла будет, разумеется, аналогично.Это формат вьюшки исхтекста совместно с комментариями (в отличие от вида только исхтекста как "схемы со снятой графикой", где и скобки двумерны, и каждой оси порядка - своя колонка). ... Структурные скобки можно изображать как графикой, так и псевдографикой (ASCII-символами для таблиц и чем-то для обозначения стрелки). Второе - для облегчённой реализации среды. Вот такую вьюшку хотелось бы видеть... |
Автор: | Дмитрий_ВБ [ Воскресенье, 03 Март, 2013 17:58 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Таблица-силуэт с горизонтальной раскладной действий для языка ДАЛВЯЗ 2 (пока не реализовано, выкладываю как материал для обсуждения) Логика работы остается той же: - во главе угла ЛСП (логическая структура процедуры), набор действий которой (подробнее см. тему "AB_VJAZ и DAL_VJAZ") опирается на постулат структурного программирования: для выполнения некоторой последовательности действий требуется следующий минимальный набор действий: 1) простое действие (присваивание, вызов процедуры); 2) ветвление (сложное условие); 3) цикл. При горизонтальной раскладке действий действия выполняются слева направо, ветка ДА условия уходит вправо, а ветка НЕТ - вверх. Т.е. условие горизонтальной раскладки - это повернутое на 90 градусов против часовой стрелки условие вертикальной раскладки, для которого ДА - вниз, НЕТ - вправо. Для условия цикла ветка ДА означает окончание цикла. Базовые элементы ЛСП для горизонтальной раскладки выглядят следующим образом: Вложение: При необходимости задания в программе сложных ветвлений необходимо воспользоваться логикой [цикла-]силуэта. Вложение: Если веток много, используем таблицу-силуэт. При этом для блоков Начало, Цикл-Силуэт, Условие Цикла-Силуэта и Конец будем использовать вертикальную раскладку. Вложение: Параллельные действия для горизонтальной раскладки 1) Алгоритм запуска параллельных действий, который может быть преобразован в исходный код Вложение: 2) Нестрогое описание параллельных действий с помощью таблицы-силуэта Вложение:
|
Автор: | Владислав Жаринов [ Воскресенье, 03 Март, 2013 18:21 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Интересно. Видимо, нестрогое описание параллелизма нужно оценить с позиций - можно ли по нему выявить проблемы, представленные здесь?.. Строгое, впрочем, тоже... |
Автор: | Владислав Жаринов [ Понедельник, 04 Март, 2013 18:08 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Вот, кстати, пример на то, что имел в виду: Геннадий Тышов писал(а): Геннадий Тышов писал(а): Возьмите ИС Дракон, составьте схему с имеющими у Вас вопросами, рассортируйте по приоритетам и последовательно их решайте, новые вопросу туда же добавляйте, общие вопросы разделите на частные. Отведите в Силуэте различные ветки для вопросов находящихся на различных этапах решения вопросов. Перемещайте иконы по мере прохождения этапов решения. В ИС Дракон имеется возможность ставить галочку рядом с иконой. Ставьте галочку у икон с решенными вопросами и Вы будите видеть соотношение между общим количеством вопросов и количеством вопросов ожидающих решение. Занимайтесь решением только одного вопроса, остальные не будут Вас напрягать, а будут существовать только в Дракон-схемах. ... Вы вроде как хотите описать принципы координации, если я верно понял. Чтобы переложить на среду (точнее, на записанный в ДАЛВЯЗ-проекте код) функции выбора работ к активации/откладыванию/снятию. Ну, понятно, в ограничениях теории расписаний, как популярно у Потопахина: viewtopic.php?p=78120#p78120. Но штука в том, что если сочинитель и опишет все правила запуска хоть и в виде текста предлагаемых схем, ему это всё равно не поможет "развернуть в бизнес-процессы" сколь-нибудь развитые структуры "вопросов, находящихся на различных этапах решения, перемещаемых по мере прохождения этапов"... И вот хотелось бы от среды на этом коде:
* учёта вещей вроде описанных тут: viewtopic.php?p=74833#p74833. Кстати, "рисунки из книги" тоже в тему... ибо взаимодействие м.б. организовано как раз через рандеву... |
Автор: | Дмитрий_ВБ [ Вторник, 05 Март, 2013 09:59 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Не, Владислав, у меня все гораздо проще. Никаких целей по выработке планов координации работ проекта или семантического анализа проекта на предмет выяснения внутренних логических несоответствий и ошибок проекта я перед собой не ставлю. Максимум, на что я претендую - это как можно более эргономичное отображение содержимого проекта и взаимосвязей между элементами проекта, причем именно тех взаимосвязей, которые явно были заданы разработчиком. Ну и дать пользователю возможность выбора: по возможности предоставить ему ту форму отображения логической структуры процедуры, с которой ему было бы удобнее работать. Т.к. ЛСП является логическим инвариантом, то для нее имеются 3 формы отображения (см. рис.): - линейная вертикальная раскладка; - линейная горизонтальная раскладка; - вертиально-горизонтальная раскладка. Вложение: Ну и остается вопрос эргономичного отображения визуальной схемы. Владимир Даниелович этот лозунг провозгласил, и 3 шага в этом направлении: 1) требование запрета пересечения линий схемы; 2) меры по пространственному структурированию схемы; 3) движение в сторону горизонтальной раскладки схемы (пп. 2 и 3 - путем введения визуально-логической конструкции "силуэт") были сделаны, но я считаю, что языку ДРАКОН полностью решить задачу эргономичного отображения визуальной схемы так и не удалось. |
Автор: | Владимир Паронджанов [ Вторник, 05 Март, 2013 12:06 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Дмитрий_ВБ писал(а): я считаю, что языку ДРАКОН полностью решить задачу эргономичного отображения визуальной схемы так и не удалось. Дмитрий Владимирович, если Вас не очень затруднит, просьба пояснить, чтО именно не удалось (желательно ответить подробно, по пунктам, с перечислением недостатков). |
Автор: | Дмитрий_ВБ [ Вторник, 05 Март, 2013 12:49 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Я конечно не спец по эргономике, поэтому мой ответ, возможно будет поверхностным, но есть следующие группы вопросов: 1. Пока эргономикой не решен вопрос количественной оценки эргономичности визуального поля, все заявления типа "у нас самая эргономичная схема" являются чисто эмоциональными заявлениями без доказательств. В качестве примера приведу вопросы, поднятые мной в теме "Просто о силуэте", которые остались без ответа: "1) какая плотность представления информации на визуальной схеме является оптимальной ? под плотностью информации на схеме я имею в виду отношение площади информационных блоков схемы к площади всего пространства схемы; (в глаза явно бросается неравномерность распределения информации на схемах языка ДРАКОН, много пустых мест, перемежающихся с заполненными участками - это не есть хорошо) 2) какая степень детализации алгоритма является оптимальной для визуальной схемы ? 3) должна ли визуальная схема по высоте обязательно целиком помещаться в окне просмотра ?" 2. Критика визуальных схем языка ДРАКОН Алексеем Донским с точки зрения видеоэкологии - не могу сказать, насколько Алексей Донской компетентен в этой дисциплине, к тому же эта критика относится не только к языку ДРАКОН, но и ко всем современным техническим схемам, но нельзя не признать, что эта критика хотя бы отчасти справедлива. Доказательство: научно-технический образ жизни, связанный с ознакомлением с научно-технической литературой, состоящей из текста, формул и чертежей, ведет к ухудшению зрения (близорукость). 3. Консервация в языке ДРАКОН представлений о программировании на уровне микроконтроллеров. - не поддерживается модульность. - не поддерживаются ссылки из схемы на структуры (типы) данных и объекты данных - не поддерживаются ссылки на внешние файлы документации (например, htm-файлы) 4. Неявно заложенная в языке ДРАКОН и весьма спорная идея о том, что никак не украшенная техническая схема, которой в сущности и является схема языка ДРАКОН, будет привлекательна не только для технических специалистов, но и для гуманитариев (см. замечания VOT7) 5. Формы блоков схемы были выбраны волевым решением автора языка, и некоторые из них не являются оптимальными, например из замечаний на формуме: - "гробики" условий; - блок комментария лучше смотрится в UML Вроде это все основные замечания по визуальным вопросам. Есть еще замечания по поводу правильности выбора названия языка и используемых в нем терминов, но к визуальному программированию это отношения не имеет, поэтому я и не хочу обсуждать этот вопрос - о нем уже достаточно сказано на форуме. |
Автор: | Дмитрий_ВБ [ Среда, 06 Март, 2013 10:09 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Все сказанное выше по поводу языка ДРАКОН вовсе не значит, что он никуда не годится. Он работает - в своей области, не хуже других аналогичных систем. Но провозглашенная Владимиром Даниеловичем цель - использовать этот язык как универсальное средство алгоритмизации - вызывает у людей ряд естественных вопросов и требований к этому универсальному средству алгоритмизации. Причем видно, что язык ДРАКОН в том виде, как он был реализован с целью создания ПО для микроконтроллеров БИСЕР, этим требованиям не удовлетворяет, а изменения, которые требуются для доведения этого языка до уровня универсального средства алгоритмизации, являются достаточно значительными и фактически требуют создания НОВОГО языка, учитывающего в полной мере запросы не только инженерно-технических работников, но и гуманитариев, не только любителей алгоритмических наворотов, но и новичков, для которых главное - сделать побыстрее и чтобы сразу заработало. Тогда зачем цепляться за старые слова и термины, которые к тому же многим не нравятся ? Сама идея создания универсального средства алгоритмизации хороша, но и реализовывать ее нужно не путем продавливания своим авторитетом уже имеющихся сейчас решений, а путем учета как можно более широкого круга мнений и при этом ставя перед собой задачу сделать этот инструмент как можно более простым и доступным. На сайте videoecology.com в разделе Книги и фильм Видеоэкология Текст - введение, заключение, содержание читаем: "Актуальность проблемы видеоэкологии еще и в том, что наука до сих пор не разработала нормативные документы по формированию визуальной среды, нет требований по допустимым отклонениям, в частности по допустимым размерам гомогенных и агрессивных полей". На мой взгляд мнение доктора биологических наук Василия Антоновича Филина - это достаточно авторитетный источник. А раз наука еще не в курсе дела, то в направлении создания универсального средства алгоритмизации нужно идти путем последовательной выработки согласованной позиции, которую бы разделяло значительное большинство компетентных специалистов, которые будут трудиться в этом направлении. Мои предложения уже во многом сформулированы в описании алгоритмического языка ДАЛВЯЗ 2 и вкратце сводятся к следующему: - в качестве логической основы: постулат структурного программирования (просто и проверено временем) плюс логика цикла-силуэта для обработки сложных логических переходов; - в качестве визуальной основы: схема с запретом на пересечение линий и пространственной структурой, задаваемой визуально-логической конструцией силуэт (таблица-силуэт) - у пользователя должна быть возможность выбирать раскладку схемы (подробнее см. в моем сообщении выше): линейная горизонтальная, линейная вертикальная или вертикально-горизонтальная; - в качестве формата данных: текстовый файл, содержащий исходный код (или псевдокод), для которого будет отображаться схема; исходный код содержит не только процедуры, но и описание данных проекта; исходный код разбивается на записи, котрые могут ссылаться друг на друга, на исхдный код других модулей проекта и на внешние htm-файлы документации; - должна быть предусмотрена возможность вставки в блоки схемы как поясняющих значков, так и полноценных изображений; - пользователь должен иметь простую возможность задания цветового оформления схемы и выбора используемых в ней шрифтов путем редактирования файлов стилей схемы. Вот как с моей точки зрения выглядят МИНИМАЛЬНЫЕ требования к универсальному средству алгоритмизации. |
Автор: | Илья Ермаков [ Среда, 06 Март, 2013 10:18 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Дмитрий_ВБ писал(а): Причем видно, что язык ДРАКОН в том виде, как он был реализован с целью создания ПО для микроконтроллеров БИСЕР, этим требованиям не удовлетворяет, а изменения, которые требуются для доведения этого языка до уровня универсального средства алгоритмизации, являются достаточно значительными и фактически требуют создания НОВОГО языка, учитывающего в полной мере запросы не только инженерно-технических работников, но и гуманитариев, не только любителей алгоритмических наворотов, но и новичков, для которых главное - сделать побыстрее и чтобы сразу заработало. Это неожиданный тезис. Я лично, например, вижу много проблем (начиная с чёткого понимания ниши) на пути в программистскую практику. И именно этого касаются, как правило, дискуссионные вопросы, поднимаемые Алексеем Донским и другими участниками форума (например, Алексей отмечал ситуации, в которых эргономические требования входят в противоречие - например, избавление от пересечения линий приводит к дублированию, а дублирование обычно воспринимается негативно, из-за возникновения нескольких мест, где нужно поддерживать изменения и проч. - это для примера противоречий, которые начинают "играть" в программисткой практике). Но все эти проблемные вопросы, которые вспоминаются мне, вообще как раз не касаются гуманитариев и обычных людей... Дракон одновременно и понятен им, и структурирует их "неформатированное математикой" мышление. Чёткие и понятные "это нельзя, а нужно вот так", исключающие разгул неупорядоченной фантазии гуманитария, начавшего рисовать Аргумент "нужны красивости, достаточно ли гуманитариям строгих схем" - не согласен. Привычки "клипового" мышления нужно ограничивать, а не потакать им. Аргумент "но и новичков, для которых главное - сделать побыстрее и чтобы сразу заработало." - тоже не согласен. Я такого рода аргумент всегда называю "Бейсик-аргументом". Именно из-за этого ошибочного мнения (потакания желанию новичка пару раз "тык-мыкнуть", не думая и не вникая, и чтобы был результат) создавались Бейсик-подобные языки и ошибочно они считаются "хорошими для начинающих", хотя, на самом деле, намертво тормозят развитие их ума в правильном направлении... |
Автор: | Дмитрий_ВБ [ Среда, 06 Март, 2013 10:35 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Цитата: Илья Ермаков пишет: Аргумент "но и новичков, для которых главное - сделать побыстрее и чтобы сразу заработало." - тоже не согласен. Я такого рода аргумент всегда называю "Бейсик-аргументом". Именно из-за этого ошибочного мнения (потакания желанию новичка пару раз "тык-мыкнуть", не думая и не вникая, и чтобы был результат) создавались Бейсик-подобные языки и ошибочно они считаются "хорошими для начинающих", хотя, на самом деле, намертво тормозят развитие их ума в правильном направлении... Даже если в основе такого "новоявленного Бейсика" будет лежать алгоритмическая логика КП (а если брать текстовый формат - то и сам КП) ? Ну а графические висюльки - когда ребенок взрослеет, он отказывается от погремушек. |
Автор: | Илья Ермаков [ Среда, 06 Март, 2013 12:33 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Смотря что Вы вкладывали в "побыстрее бы заработало". Последнее Ваше высказывание ясности не добавляет.... Что именно Вы считаете препятствием для новичком на пути к "побыстрее бы заработало"? |
Автор: | Дмитрий_ВБ [ Среда, 06 Март, 2013 13:24 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Тут все зависит от того, для чего используется среда. Если гуманитарий рисует в ней какой-нибудь алгоритм, то "побыстрее бы заработало" означает преодоление им порога уверенного пользователя средой плюс эргономичность средств создания алгоритма. На выходе в текстовом формате будем иметь псевдокод алгоритма и, конечно схему алгоритма. А если мы имеем в виду студента, обучающегося программированию, то на выходе будут алгоритм процедуры и исходный код, назначение каждой строки которого студент по идее должен бы ясно понимать, даже если маршрутные операторы условий и циклов будут генериться автоматиески. Ведь сами условия и текст действий все-равно придется вводить вручную (тут же не предполагается такого автоматизма, как у Валерия Лаптева - вот он даже и текстовый редактор в процессе обучения программированию требует запретить). Ну а побыстрее заработало - это чтобы программа поыстрее заработала правильно. Понятно, что студент и преподаватель вкладывают в эту фразу разный смысл, ну так я ведь и не преподаватель. Я и не брал на себя роль сводильщика воедино и модератора всех поступающих предложений по поводу возможной спецификации для универсального средства алгоритмизации. Возможно эта роль больше подходит Вам, Илья. А главное в этом вопросе - чтобы народ откликнулся и выдал свои предложения и замечания - тогда и будет, над чем подумать. |
Автор: | Илья Ермаков [ Среда, 06 Март, 2013 14:55 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Понял Ваши мысли. По поводу ДРАКОНа и его связи с развитием визуальных средств в целом, я придерживаюсь мнения о "локальном оптимуме". Т.е. усовершенствованиям он не поддаётся, он хорошо "отточен" в конкретном, локально хорошем соотношении - туда-сюда в нём и подвигать особо нечего... А новые средства хотелось бы проектировать не только из требований когнитивной эргономики, но и исходя из общего понимания проектирования... На какую тему всегда сворачивает Алексей Донской: как мне зафиксировать всю последовательность поиска окончательного решения? |
Автор: | Дмитрий_ВБ [ Вторник, 20 Август, 2013 18:41 ] |
Заголовок сообщения: | Re: КУБ-СИЛУЭТ и ТАБЛИЦА-СИЛУЭТ, текст -> схема |
Схемы данных в ДАЛВЯЗ 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 для приведенного псевдокода построит следующую схему: Вложение: Примерно так же можно описывать и отображать структуру таблиц или обобщенную структуру данных для объектов разных типов, имеющих как общие поля данных, так и уникальные для каждого типа объекта. |
Страница 2 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |