OberonCore

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

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




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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
КУБ-СИЛУЭТ
Цитата:
Дмитрий_ВБ пишет:
Программа строится как схема (возможно 3D) из блоков, сдержимое которых может задаваться
текстом, голосом, мыслью или путем выбора из меню

Цитата:
Сергей Прохоренко пишет:
3D - это вообще завиральное детище режиссеров киберпанка. Мне нравится этот жанр, но иногда
он вызывает смех


«Постиг я, сколько будет семью семь». Волшебник из сказки "Король-олень"


При обсуждении на формуме темы визуального программирования очень часто
следуют отсылки к эргономике, но один достаточно распространенный закон
эргономики/психологии, как мне кажется, остался в стороне от обсуждения.
Я имею в виду "закон десяти пальцев", если использовать его жагронное
название:
"Если в поле зрения человека находится одновременно больше 10 (некоторые
источники говорят о 9, 8, 7, а известная поговорка - даже о 3-х объектах)
объектов, то уследить за всеми этими объектами одновременно человек
физически не в состоянии".
Причем форма представления этих объетов - текст или графика - здесь
значения не имеет.
В эргономике борются с этим эффектом путем группировки кнопок/клавиш/
тумблеров/переключателей со сходными функциями в общие функциональные
группы (в силуэте роль таких групп выполняют ветки).
Но эргономика помогает только до поры: если число групп (веток силуэта)
становится больше 7 (или 8, или 9, или 10), то сложность катринки
начинает превышать возможности восприятия, что ведет к неизбежным ошибкам
оператора (программиста).
Борьба со сложностью - дробление информационного поля с целью снижения
сложности восприятия.
В программировании это означает декомпозицию процедуры. Правда с точки
зрения визуального программирования тут есть недостаток - ссылки на
другие процедуры являются гипертекстовыми, а не визуальными.

Может ли здесь помочь 3D ?
Я обдумал этот вопрос и пришел к понятию "куб-силуэт".

С точки зрения программной реализации это по-прежнему цикл-силуэт (он же
цикл Дейкстры) - подробнее см. тему "программы AB_VJAZ и DAL_VJAZ".
А вот с визуальной точки зрения куб-силуэт представляет собой трехмерную
фигуру, которая может включать в себя до семи слоев, каждый из которых
является подсилуэтом, т.е. частью силуэта, включающей в себя ветки с
номерами своего слоя:
слой один - ветки 1, 2, 3, 4, 5, 6, 7
слой два - ветки 11, 12, 13, 14, 15, 16, 17
слой три - ветки 21, 22, 23, 24, 25, 26, 27
слой четыре - ветки 31, 32, 33, 34, 35, 36, 37
слой пять - ветки 41, 42, 43, 44, 45, 46, 47
слой шесть - ветки 51, 52, 53, 54, 55, 56, 57
слой семь - ветки 61, 62, 63, 64, 65, 66, 67

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

Вложение:
kub.jpg
kub.jpg [ 92.66 КБ | Просмотров: 17930 ]


Для сравнения привожу снятую мной стереопару летнего леса.

Вложение:
les.JPG
les.JPG [ 41.77 КБ | Просмотров: 17930 ]


На экране возможен и более простой вариант, чем реализация
стереоизображения.
Старшие слои распологаются с некоторым сдвигом вправо относительно
младших, причем это расстояние можно менять при помощи бегунка.
Когда бегунок в крайней правой позиции, то сдвиг старших слоев
максимален, а когда в крайней левой - то сдвиг слоев равен 0 и старшие
слои будут находиться точно над младшими.
Если двигать бегунок туда-сюда, то это делает более удобным процесс
отслеживания взаимных связей между слоями, если их много и они
накладываются друг на друга (но опять же, это помогает, пока связей
между слоями не слишком много).
Любая связь между слоями начинается от блока перехода к следующей ветке
одного слоя и заканчивается заголовком (условием) ветки другого слоя.
Для каждого слоя переходы к другим слоям имеют свои цвета:
слой 1 - голубой
слой 2 - светло-зеленый
слой 3 - синий
слой 4 - зеленый
слой 5 - сиреневый
слой 6 - фиолетовый
слой 7 - оранжевый
выход из куба-силуэта - белый
блоки переходов, ведущие в никуда, закрашиваются черным.

Вложение:
dv2view.JPG
dv2view.JPG [ 125.63 КБ | Просмотров: 17930 ]


Последний раз редактировалось Дмитрий_ВБ Вторник, 03 Июль, 2012 13:38, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Понедельник, 11 Июнь, 2012 20:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Дмитрий_ВБ писал(а):
КУБ-СИЛУЭТ
...
При обсуждении на формуме темы визуального программирования очень часто
следуют отсылки к эргономике, но один достаточно распространенный закон
эргономики/психологии, как мне кажется, остался в стороне от обсуждения.
Я имею в виду "закон десяти пальцев", если использовать его жагронное
название:
"Если в поле зрения человека находится одновременно больше 10 (некоторые
источники говорят о 9, 8, 7, а известная поговорка - даже о 3-х объектах)
объектов, то уследить за всеми этими объектами одновременно человек
физически не в состоянии".
Причем форма представления этих объетов - текст или графика - здесь
значения не имеет.
Да где-то его вспоминали... Донской вроде. Бытовых-то названий много (скажем "закон численности подчинённых") - а официально это число Ингве-Миллера (7+-3). Там да, штука в однородности восприятия/оперирования с объектами.
Дмитрий_ВБ писал(а):
...
В программировании это означает декомпозицию процедуры. Правда с точки
зрения визуального программирования тут есть недостаток - ссылки на
другие процедуры являются гипертекстовыми, а не визуальными.

Может ли здесь помочь 3D ?
Я обдумал этот вопрос и пришел к понятию "куб-силуэт".

С точки зрения программной реализации это по-прежнему цикл-силуэт (он же
цикл Дейкстры) - подробнее см. тему "программы AB_VJAZ и DAL_VJAZ".
А вот с визуальной точки зрения куб-силуэт представляет собой трехмерную
фигуру, которая может включать в себя до семи слоев, каждый из которых
является подсилуэтом, т.е. частью силуэта, включающей в себя ветки с
номерами своего слоя:
слой один - ветки 1, 2, 3, 4, 5, 6, 7
слой два - ветки 11, 12, 13, 14, 15, 16, 17
слой три - ветки 21, 22, 23, 24, 25, 26, 27
слой четыре - ветки 31, 32, 33, 34, 35, 36, 37
слой пять - ветки 41, 42, 43, 44, 45, 46, 47
слой шесть - ветки 51, 52, 53, 54, 55, 56, 57
слой семь - ветки 61, 62, 63, 64, 65, 66, 67
...
Так это типа как ДМ-О2-схема здесь - только каждому этажу строго соответствует свой уровень декомпозиции? и напрямую (минуя кросс) м.б. показаны связи веток (типа как зависимости ячеек поверх динамической таблицы)?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Понедельник, 18 Июнь, 2012 12:53 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
а официально это число Ингве-Миллера (7+-3).
Про это дело Паронджанов убедительно объяснил, что напрасно распространяют на всю мыслительную деятельность. Все исследования, откуда число вылезло, касались исключительно восприятия рекламы. :D


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Понедельник, 18 Июнь, 2012 13:08 

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

Но откуда тогда взялась поговорка о блуждающем в трех соснах (а если их триста?) ?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Понедельник, 18 Июнь, 2012 14:12 
Аватара пользователя

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

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

Человек вроде как работает в контексте. И этот контекст загружается в течение некоторого времени. Но, по-видимому, он вовсе не размещается в оперативной памяти. Скорее, штатно он удерживается периферийным зрением (собственно, этому у Паронджанова и отведено значительное место). Если лишить человека такой поддержки, возникает стресс (потому что приходится держать контекст в памяти, а это очень накладно).

И ещё есть фокус (внимания, восприятия, операций). Я бы предложил исходить из того, что в фокусе отнюдь не 3 или 7 предметов, а 1 (то есть сознание, в терминах компьютерных, однозадачно).

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

Всё сказанное - имхо и экспромт, так что можно критиковать... а также взять на вооружение... вдруг что путное выйдет :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Пятница, 22 Июнь, 2012 16:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Устройство памяти недавно стали активно изучать нейробиологи (возможно, скорее активно публиковать результаты исследований). Навскидку помню какую-то лабораторию с руководителем по фамилии Афанасьев и группу, руководитель которой выступал с лекцией на эту тему в проекте ACADEMIA. :) Результаы, сколько помню, в чём-то пересекаются со сказанным в предыдущем посте.

И возвращаясь к топику - всё-таки насколько верно я понял идею такой схемы?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Пятница, 22 Июнь, 2012 16:33 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Ну конечно же, Владислав, Вы все поняли првильно.
В каком-то смысле это просто новое художественное оформление.
Ну и Сергей Прохоренко меня раззадорил - да неужто мы, сторонники силуэтного программирования,
не сможем по-бысторму настрогать осмысленный макет 3D-схемы, которая и ляжет в основу
3D-программирования ?
Другое дело, насколько это удобно ...

Кстати, спасибо за информцию о книге "Проект Оберон" - просмотрел и решил купить
себе бумажную книгу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Вторник, 26 Июнь, 2012 10:56 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Кстати, если вынести за скобки модерновые дизайнерские навороты типа цветных лучей-связей, то
куб-силуэт без проблем может быть создан в программе dal_vjaz_2, выложенной мной 17.03.12 в
теме "AB_VJAZ и DAL_VJAZ'.

Вот так выглядит скриншот:
Вложение:
kub.JPG
kub.JPG [ 308.42 КБ | Просмотров: 17680 ]


А это исходный код куба-силуэта в dal_vjaz_2 для паскаля:
Код:

(* t.0. *)
unit u_test1;

interface   // что-нибудь  _>2.2  _>1#2 _>1#3  _>1.ququ  _>.2. _>.3. _>.4.

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;

implementation

{$R *.DFM}

(* i.1. kub_siluet *)

procedure  kub_siluet;
   (*i*)
   begin
   (*i CB *)
      (*i*)  if (wetka = 61)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 62;
      (*i*)  end else if (wetka = 62)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 62;
      (*i*)  end else if (wetka = 63)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 62;
      (*i*)  end else if (wetka = 64)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 62;
      (*i*)  end else if (wetka = 65)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 62;
      (*i*)  end else if (wetka = 66)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 62;
      (*i*)  end else if (wetka = 67)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 62;
      (*i*)  end;
      (*i*)  if (wetka = 51)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 52;
      (*i*)  end else if (wetka = 52)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 52;
      (*i*)  end else if (wetka = 53)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 52;
      (*i*)  end else if (wetka = 54)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 52;
      (*i*)  end else if (wetka = 55)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 4;
      (*i*)  end else if (wetka = 56)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 52;
      (*i*)  end else if (wetka = 57)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 52;
      (*i*)  end;
      (*i*)  if (wetka = 41)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 42;
      (*i*)  end else if (wetka = 42)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 42;
      (*i*)  end else if (wetka = 43)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 42;
      (*i*)  end else if (wetka = 44)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 42;
      (*i*)  end else if (wetka = 45)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 42;
      (*i*)  end else if (wetka = 46)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 42;
      (*i*)  end else if (wetka = 47)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 42;
      (*i*)  end;
      (*i*)  if (wetka = 31)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 32;
      (*i*)  end else if (wetka = 32)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 32;
      (*i*)  end else if (wetka = 33)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 32;
      (*i*)  end else if (wetka = 34)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 32;
      (*i*)  end else if (wetka = 35)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 32;
      (*i*)  end else if (wetka = 36)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 32;
      (*i*)  end else if (wetka = 37)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 32;
      (*i*)  end;
      (*i*)  if (wetka = 21)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 22;
      (*i*)  end else if (wetka = 22)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 22;
      (*i*)  end else if (wetka = 23)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 22;
      (*i*)  end else if (wetka = 24)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 22;
      (*i*)  end else if (wetka = 25)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 22;
      (*i*)  end else if (wetka = 26)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 22;
      (*i*)  end else if (wetka = 27)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 22;
      (*i*)  end;
      (*i*)  if (wetka = 11)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 12;
      (*i*)  end else if (wetka = 12)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 12;
      (*i*)  end else if (wetka = 13)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 12;
      (*i*)  end else if (wetka = 14)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 12;
      (*i*)  end else if (wetka = 15)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 12;
      (*i*)  end else if (wetka = 16)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 12;
      (*i*)  end else if (wetka = 17)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 12;
      (*i*)  end;
      (*i*)  if (wetka = 1)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 11;
      (*i*)  end else if (wetka = 2)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 21;
      (*i*)  end else if (wetka = 3)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 51;
      (*i*)  end else if (wetka = 4)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 2;
      (*i*)  end else if (wetka = 5)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 2;
      (*i*)  end else if (wetka = 6)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 2;
      (*i*)  end else if (wetka = 7)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)
         (*i*)  wetka := 0;
      (*i*)  end;
   (*i CE *)
   (*i ВЫХОД *)
   end;
(*i КОНЕЦ *)


(* t.100. *)

end.



Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Вторник, 26 Июнь, 2012 11:33 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
И приходим к просто-табличному-представлению... Которое второе по универсальности после текстового. Специализированная графика - только после них...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Вторник, 26 Июнь, 2012 12:11 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Вторник, 26 Июнь, 2012 13:38 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Илья Ермаков писал(а):
И приходим к просто-табличному-представлению... Которое второе по универсальности после текстового. Специализированная графика - только после них...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Пятница, 29 Июнь, 2012 09:57 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
ТАБЛИЦА-СИЛУЭТ
Илья Ермаков писал(а):
И приходим к просто-табличному-представлению...

С учетом замечания Ильи Ермакова и правила структурного программирования,
рекомендующего четко разделять логику программы на логику верхнего уровня
и процедуры-обработчики, ввожу новую раскладку куба-силуэта на плоскость,
в которой самый ближний слой куба находится сверху, и называю ее
"ТАБЛИЦА-СИЛУЭТ".

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

Ниже приведены скриншот и исходный код таблицы-силуэта:
Вложение:
tabsil.JPG
tabsil.JPG [ 80.87 КБ | Просмотров: 17593 ]

Код:
(* t.0. *)
unit u_test1;

interface   // что-нибудь  _>2.2  _>1#2 _>1#3  _>1.ququ  _>.2. _>.3. _>.4.

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;

implementation

{$R *.DFM}

(* i.1. tablica_siluet *)

procedure  kub_siluet;
var n:integer;
   (*i CB *)  wetka := 1;   while (wetka <> 0)  do  begin
      (*i*)  if (wetka = 1)
         (*i*)  k := 1;
                n := 1;
         (*i*)  wetka := 2;
      (*i*)  end else if (wetka = 2)
         (*i*)  // вход в основной режим
         (*i*)  wetka := 61;
      (*i*)  end else if (wetka = 3)
         (*i*)  if (n = 2)  then begin      (*рис . . Д1 *)
            (*i*)  wetka := 62;   // подрежим 1
         (*i*)  end else if (n = 3) then begin   (*рис . . Д2 *)
            (*i*)  wetka := 63;   // подрежим 2
         (*i*)  end else if (n = 4) then begin   (*рис . . Д3 *)
            (*i*)  wetka := 64;   // подрежим 3
         (*i*)  end;
      (*i*)  end else if (wetka = 4)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 5;
      (*i*)  end else if (wetka = 5)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 6;
      (*i*)  end else if (wetka = 6)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 7;
      (*i*)  end else if (wetka = 7)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 11;
      (*i*)  end;
      (*i*)  if (wetka = 11)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 12;
      (*i*)  end else if (wetka = 12)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 13;
      (*i*)  end else if (wetka = 13)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 14;
      (*i*)  end else if (wetka = 14)
         (*i*) // делаем что-нибудь
         (*i*)  wetka := 15;
      (*i*)  end else if (wetka = 15)
         (*i*) // делаем что-нибудь
         (*i*)  inc(k);
         (*i*)  wetka := 16;
      (*i*)  end else if (wetka = 16)
         (*i*)  if (k < 10)  then begin
            (*i*)  wetka := 2;
         (*i*)  end else begin
            (*i*)  wetka := 17;
         (*i*)  end;
      (*i*)  end else if (wetka = 17)
         (*i*)  // обработка ошибок
         (*i*)  wetka := 0;
      (*i*)  end;
      (*i*)  if (wetka = 61)
         (*i*) // загрузка параметров
         (*i*) // вызов процедуры-обработчика
         (*i*) // обработка ответа процедуры обработчика
               // получаем значение n
         (*i*)  wetka := 3;
      (*i*)  end else if (wetka = 62)
         (*i*) // загрузка параметров
         (*i*) // вызов процедуры-обработчика
         (*i*) // обработка ответа процедуры обработчика
         (*i*)  wetka := 4;
      (*i*)  end else if (wetka = 63)
         (*i*) // загрузка параметров
         (*i*) // вызов процедуры-обработчика
         (*i*) // обработка ответа процедуры обработчика
         (*i*)  wetka := 4;
      (*i*)  end else if (wetka = 64)
         (*i*) // загрузка параметров
         (*i*) // вызов процедуры-обработчика
         (*i*) // обработка ответа процедуры обработчика
         (*i*)  wetka := 4;
      (*i*)  end;
   (*i CE *)  end;
   (*i ВЫХОД *)
   end;
(*i КОНЕЦ *)

(* t.100. *)

end.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Воскресенье, 01 Июль, 2012 00:32 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
ТЕХНОЛОГИЯ РАБОТЫ С ТАБЛИЦЕЙ-СИЛУЭТОМ

Выкладываю обещанный просмотрщик полной формы визуальной схемы для
языка ДАЛВЯЗ 2, версия 0.8, в архиве dal2v08.rar находятся
исполняемый файл с примерами и исходный код, размер исходного кода
примерно 190К и чуть меньше 6000 строк.
Вроде работает, хотя особо сильно я его не гонял.
Выложено для дальнейшего развития всеми желающими.

Можно работать с языками семейств Pascal и C/C++ и с псевдокодом.
В файле dalvjaz.cfg - настройки для паскаля
В файле dalvjaz.cf1 - настройки для псевдокода
В файле dalvjaz.cf2 - настройки для C/C++

Кстати, перед запуском не забудьте правильно настроить каталоги в
файле dalvjaz.cfg.

Просмотрщик запускается, а затем Файл исходного кода со служебными
комментариями ДАЛВЯЗ 2 (подробнее см. тему на форуме сайта oberoncore.ru,
тема ДРАКОН -> Инструменты ДРАКОН-схем -> программы AB_VJAZ и DAL_VJAZ,
начиная с ноября 2011 г.) редактируется в текстовом редакторе.
После нажатия клавиши "Сохранить" изменения сразу же отображаются в
просмотрщике. При возникновении проблем с чтением ошибка указывается
в строке состояния.
Краткий перечень наиболее важных ошибок:

'Нет ЕС для ИЕ' - нет ЕСЛИ для ИНАЧЕ ЕСЛИ;

'Нет ЕС для ИН' - нет ЕСЛИ для ИНАЧЕ;

'Нет ЕС для К' - нет ЕСЛИ для конца блока ЕСЛИ;

'Нет НЦ для КЦ' - нет начала цикла для конца цикла;

'Незакрытый ЕС для КЦ' - незакрытый ЕСЛИ для конца цикла;

'Незакрытый ИЕ для КЦ' - незакрытый ИНАЧЕ ЕСЛИ для конца цикла;

'Незакрытый ИН для КЦ' - незакрытый ИНАЧЕ для конца цикла;

'Незакрытый НЦ для ИЕ' - незакрытый цикл для ИНАЧЕ ЕСЛИ;

'Незакрытый НЦ для ИН' - незакрытый цикл для ИНАЧЕ;

'Незакрытый НЦ для К' - незакрытый цикл для конца блока ЕСЛИ;

'Повтор ИН' - повтор ИНАЧЕ;

'Незакрытый ИН для ИЕ' - незакрытый ИНАЧЕ для ИНАЧЕ ЕСЛИ.

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

Выяснилось, что для таблицы-силуэта удобно объединять несколько
веток в одну строку при помощи блока ЕСЛИ, например:

(*i*) if (wetka = 1) then begin
(*i*) k := 1;
n := 1; //_>.1
(*i*) wetka := 2;
(*i*) end else if (wetka = 2) then begin
(*i*) // вход в основной режим
(*i*) wetka := 61;
(*i*) end;

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

Почему у блоков условий на схеме нет надписей ДА и НЕТ ?
Потому что в ДАЛВЯЗ 2 принято правило, что ДА - это всегда вниз,
а НЕТ - всегда вправо.

При наведении мышки на блок схемы всплывает окошко, в верхней строке
которого в скобках указана строка файла исходного кода, соответствующая
началу блока, а ниже следует содержание блока. Если в блоке есть
гиперссылки (см. dalvjaz.cfg), то во всплывающем окне они будут
доступны, надо только БЫСТРО передвинуть указатель мыши на всплывающее
окно, чтобы оно до этого не закрылось. Возврат из внутренней
гиперссылки по кнопке "<".

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

Вот вкратце и все о просмотрщике. Теперь о таблице-силуэте.


Предлагается следующая технология работы с таблицей-силуэтом.

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

Вот как-то так получается.

dal2v08.rar - 24 скачивания, новую версию см. в теме AB_VJAZ и DAL_VJAZ, сообщение от 4.12.2012

Вложение:
shema.JPG
shema.JPG [ 210.16 КБ | Просмотров: 17474 ]


Последний раз редактировалось Дмитрий_ВБ Вторник, 04 Декабрь, 2012 00:41, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: КУБ-СИЛУЭТ
СообщениеДобавлено: Воскресенье, 01 Июль, 2012 09:47 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Не как обязательно для автора - он делает интересные вещи - просто в качестве развития:
Дмитрий_ВБ писал(а):
Краткий перечень наиболее важных ошибок:

'Нет ЕС для ИЕ' - нет ЕСЛИ для ИНАЧЕ ЕСЛИ;

'Нет ЕС для ИН' - нет ЕСЛИ для ИНАЧЕ;

'Нет ЕС для К' - нет ЕСЛИ для конца блока ЕСЛИ;
...
Ну, сокращения, наверное, неэргономичны...

А вообще перечисленные ошибки объединяет ситуация - они возникают как следствие нарушения принципов: вложения составных операторов как одноимённых атомов; добавления/удаления логически целостных частей. Если вкладываем сразу "Развилку" (т.е. ЕСЛИ-ТО-ВСЁ) и прибавляем/вычитаем из неё только ветвями (т.е. <ТО|ИНАЧЕ>-ВСЁ) - такие ошибки не возникают в принципе. И редактор эргономичный для сочинителя должен в итоге это поддерживать.

Дмитрий_ВБ писал(а):
...
Выяснилось, что для таблицы-силуэта удобно объединять несколько
веток в одну строку при помощи блока ЕСЛИ, например:

(*i*) if (wetka = 1) then begin
(*i*) k := 1;
n := 1; //_>.1
(*i*) wetka := 2;
(*i*) end else if (wetka = 2) then begin
(*i*) // вход в основной режим
(*i*) wetka := 61;
(*i*) end;

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

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

Дмитрий_ВБ писал(а):
...
При наведении мышки на блок схемы всплывает окошко, в верхней строке
которого в скобках указана строка файла исходного кода, соответствующая
началу блока, а ниже следует содержание блока. Если в блоке есть
гиперссылки (см. dalvjaz.cfg), то во всплывающем окне они будут
доступны, надо только БЫСТРО передвинуть указатель мыши на всплывающее
окно, чтобы оно до этого не закрылось. Возврат из внутренней
гиперссылки по кнопке "<".
Насколько БЫСТРО?.. :) Оно ведь тоже эргономика...
А вообще реализация связности и атрибутов-примечаний - рулез.


Дмитрий_ВБ писал(а):
...
Предлагается следующая технология работы с таблицей-силуэтом.

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

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

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

Такой процесс будет чреват ещё меньшими ошибками (во многом из-за меньших трудозатрат и участников - той же секретарши с Пайнтом).

Вот как-то так... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ТАБЛИЦА-СИЛУЭТ
СообщениеДобавлено: Понедельник, 02 Июль, 2012 09:52 

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: текст -> схема
СообщениеДобавлено: Вторник, 03 Июль, 2012 13:54 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
Цитата:
Сергей Прохоренко пишет:
Кстати, создатели Дракона не задумывались над обратной задачей:
генерировать дракон-схемы по коду на ЯВУ ...
...
Дракон - это блок-схема 2D, манипулирование которой неоправданно трудоемко

Цитата:
VOT7 пишет:
Также хочу опять высказать ту идею, о которой уже не раз говорил.
Пока не будет выпущена простая, эргономичная, доступная программа
для рисования схем на ДРАКОН, ГНОМ и ГРАФ - путь гуманитариям к
этим языкам закрыт.


Я думаю, что хотя VOT7 и не технарь, но он должен бы разобраться, что
написано в нижеследующем тексте:
Код:
АЛГОРИТМ.4. ТАБЛИЦА-СИЛУЭТ
   * ветка := 1
   * цикл-силуэт пока (ветка <> 0)
      * если (ветка = 1)
         * k := 1;
           n := 1;   
         * ветка := 2;
      * иначе если (ветка = 2)
         * ветка := 61
           вход в основной режим
      * конец
      * если (ветка = 3)
         * если (n = 2)
            * ветка := 62
         * иначе если (n = 3)
            * ветка := 63
         * иначе если (n = 4)
            * ветка := 64
         * конец
      * конец
      * если (ветка = 4)
         * делаем что-нибудь
         * ветка := 5
      * иначе если (ветка = 5)
         * делаем что-нибудь
         * ветка := 6
      * иначе если (ветка = 6)
         * делаем что-нибудь
         * ветка := 7
      * конец
      * если (ветка = 7)
         * делаем что-нибудь
         * ветка := 11
      * иначе если (ветка = 11)
         * делаем что-нибудь
         * ветка := 12
      * иначе если (ветка = 12)
         * делаем что-нибудь
         * ветка := 13
      *  конец
      * если (ветка = 13)
         * делаем что-нибудь
         * ветка := 14
      *  иначе если (ветка = 14)
         * делаем что-нибудь
         * ветка := 15
      *  иначе если (ветка = 15)
         * делаем что-нибудь
         * к := к+1
         * ветка := 16
      * конец
      * если (ветка = 16)
         * если (k < 10)
            * ветка := 2
         * иначе
            * ветка := 17
         * конец
      * иначе если (ветка = 17)
         * обработка ошибок
         * ветка := 0
      * конец
      * если (ветка = 61)
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
           получаем значение n
         * ветка := 3
      * иначе если (ветка = 62)
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
         * ветка := 4
      *  конец
      * если (ветка = 63)
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
         * ветка := 4
      * иначе если (ветка = 64)
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
         * ветка := 4
      * конец
   * конец цикла-силуэта   
   * выход
КОНЕЦ АЛГОРИТМА


Сгенерированная на основе этого псевдокода схема приведена в сообщении от 1.07.12 00:32
После запуска программы можно редактировать псевдокод в текстовом редаторе,
и после нажатия клавиши "Сохранить" изменения отразятся в просмотрщике dal_2_view,
в его окне просмотра схемы.

===================================

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

Она позволяет генерировать из исходного кода на языках Pascal и C/C++,
а также из псевдокода с маршрутными операторами в стиле языка Oberon
структурные блок-схемы в стиле языка ДРАКОН.

Для чего это нужно ?
1) См. выше, технология использования визуальной схемы ТАБЛИЦА-СИЛУЭТ,
т.е. никакого баловства - тут работа по согласованию реальных
ответственных алгоритмов.
2) возможно, некоторые программисты захотят сами для себя визуализировать
свои алгоритмы - dal_2_view позволит вам это сделать не хуже других
программ-построителей блок-схем, к тому же она дает возможность
программисту самому решать, какие участки программного кода будут
включены в тот или иной блок визуальной схемы.
К тому же dal_2_view позволяет создавать блок-схемы для достаточно
сложных, но удобочитаемых алгоритмов - визуальная схема ТАБЛИЦА-СИЛУЭТ
решает эту задачу.
3) обучение - ученики пишут псевдокод и сразу видят, какая блок-схема
этому псевдокоду соответствует.


Если кто-нибудь станет использовать dal_2_view и у него появятся замечания
и предложения - пишите. Выявленные ошибки буду исправлять.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: текст -> схема
СообщениеДобавлено: Пятница, 06 Июль, 2012 10:29 

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

Я думаю, что хотя VOT7 и не технарь, но он должен бы разобраться, что
написано в нижеследующем тексте:
Код:
 АЛГОРИТМ.4. ТАБЛИЦА-СИЛУЭТ
  ...
КОНЕЦ АЛГОРИТМА
Возможно, не технарю проще было бы разбираться в тексте с явным выделением разных (по "классификации знаний, отчуждаемых в программе" согласно В.Д.) составляющих. Скажем, так, как делают в некоторых книгах по Оберонам - маршрутная лексика прописными, идентификаторы курсивом и/или иной гарнитурой.

Дмитрий_ВБ писал(а):
...
Сгенерированная на основе этого псевдокода схема приведена в сообщении от 1.07.12 00:32
После запуска программы можно редактировать псевдокод в текстовом редаторе,
и после нажатия клавиши "Сохранить" изменения отразятся в просмотрщике dal_2_view,
в его окне просмотра схемы.

===================================

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

Она позволяет генерировать из исходного кода на языках Pascal и C/C++,
а также из псевдокода с маршрутными операторами в стиле языка Oberon
структурные блок-схемы в стиле языка ДРАКОН.

Для чего это нужно ?
1) См. выше, технология использования визуальной схемы ТАБЛИЦА-СИЛУЭТ,
т.е. никакого баловства - тут работа по согласованию реальных
ответственных алгоритмов.
2) возможно, некоторые программисты захотят сами для себя визуализировать
свои алгоритмы - dal_2_view позволит вам это сделать не хуже других
программ-построителей блок-схем, к тому же она дает возможность
программисту самому решать, какие участки программного кода будут
включены в тот или иной блок визуальной схемы.
К тому же dal_2_view позволяет создавать блок-схемы для достаточно
сложных, но удобочитаемых алгоритмов - визуальная схема ТАБЛИЦА-СИЛУЭТ решает эту задачу.
3) обучение - ученики пишут псевдокод и сразу видят, какая блок-схема
этому псевдокоду соответствует.
...
Это так, и это отлично - что идёт от практики и в ней применяется. И в перспективе смотритель и транслятор должны составлять единое целое - поддерживая технологию именно Разработки-Документирования...

Ну, ГНОМ и ГРАФ - это в сущности, элементы языка схематизации документов (скажем, лист-силуэтного)...


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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 164
ЛОГИЧЕСКАЯ СТРУКТУРА ПРОЦЕДУРЫ и ТАБЛИЦА-СИЛУЭТ
(мысли по дальнейшему развитию программы)

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

В ДАЛВЯЗ 2 действие (присвоение или вызов процедуры или группа
каких-нибудь операторов языка программирования), обобщенный цикл и
сложное условие являются основными маршрутными операторами, полноценно
отображаемыми на визуальной схеме в виде блоков действий, связанных
между собой линиями логических переходов, и задаваемыми псевдокодом
ПкДАЛВЯЗ в окне ЛСП при создании и редактировании визуальной схемы.
Логическая структура процедуры (ЛСП) - это последовательность основных
маршрутных операторов, укрупненно описывающая логику процедуры
(подробнее см. тему "AB_VJAZ и DAL_VJAZ, 6.04.2012, dalvjaz2_description.pdf).

При считывании исходного кода программа разделяет его на ЛСП и список
соответствующих каждой строке ЛСП действий.

1) Последняя версия ПкДАЛВЯЗ (планируется ее вставка в программу как одного
из первоочередных исправлений при дальнейшем развитии программы)
выглядит следующим образом:
Код:
Назначение операторов                      английская  русская
ПкДАЛВЯЗ                                   мнемоника   мнемоника

Начало процедуры                            HD  NA      ПР  НД   (процедура)
Начало блока условия с номером действия     IF  NA      ЕС  НД   (если )
Дополнительное условие с н. действия        EI  NA      ИЕ  НД   (иначе если)
Альтернативное условие                      EL          ИН       (иначе)
Конец блока условия                         E           К        (конец)
Начало цикла с н. действия                  CB  NA      НЦ  НД   (начало цикла)
Конец цикла с н. действия                   CE  NA      КЦ  НД   (конец цикла)
Действие с н. действия                      А   NA      Д   НД   (действие)
Первая ветка блока веток с номером ветки     
и н. действия                               FB  NB NA   ПВ  НВ НД
Следующая ветка блока веток с н. ветки     
и н. действия                               NB  NB NA   СВ  НВ НД
Переход к ветке с н. ветки и н. действия    J   NB NA   П   НВ НД
Выход из процедуры с н. действия            R   NA      В   НД   

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

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


2) Предполагается, что в следующей версии программы ЛСП будет не списком,
а текстом в окне редактирования, который пользователь сможет вводить как
функциональными клавишами, так и с клавиатуры.
В нужные места ЛСП можно будет по Shift+Ins вставлять фрагменты ЛСП,
взятые из файлов шаблонов ЛСП.
Список действий будет представлен как текст в окне редактирования,
находящемся ниже окна ЛСП.
При щелчке мышью по номеру действия в окне ЛСП в окне действий будет
появляться действие с этим номером.
Пара "ЛСП + список действий" будет рассматриваться как текущее состояние
редактирования схемы, все состояния будут сохраняться в каталоге состояний
редактирования схемы, так что после начала редактирования будет возможен
откат к любому из состояний после начала редактирования.


3) Предполагается приблизить формат псевдокода к формату текстовой
инструкции.
Будет считаться, что строка первой или следующей ветки блока веток
обозначается числом, соответствующим номеру ветки, за которым следуют
символы "точка" и "пробел".
Если после текущий ветки сразу же будет выполняться следующая ветка, то
переход к следующей ветке, являющийся последним действием ветки, можно не
ставить. Переход в конце ветки также не нужен, если в теле ветки задается
несколько переходов (например с помощью блока переключателей).

(можно сравнить приводимый ниже текст с текстом алгоритма 4 выше в этой теме
из поста от 3.07.2012 )
Код:
АЛГОРИТМ.4. ТАБЛИЦА-СИЛУЭТ
   * ветка := 1
   * цикл-силуэт пока (ветка <> 0)
      1. описание действий для ветки
         * k := 1;
           n := 1;   
      2. описание действий для ветки
         * переход к 61
           вход в основной режим
      * конец
      3. описание действий для ветки
         * если (n = 2)
            * переход к 62
         * иначе если (n = 3)
            * переход к 63
         * иначе если (n = 4)
            * переход к 64
         * конец
      * конец
      4. описание действий для ветки
         * делаем что-нибудь
      5. описание действий для ветки
         * делаем что-нибудь
      6. описание действий для ветки
         * делаем что-нибудь
      * конец
      7. описание действий для ветки
         * делаем что-нибудь
      11. описание действий для ветки
         * делаем что-нибудь
      12. описание действий для ветки
         * делаем что-нибудь
      * конец
      13. описание действий для ветки
         * делаем что-нибудь
      14. описание действий для ветки
         * делаем что-нибудь
      15. описание действий для ветки
         * делаем что-нибудь
         * к := к+1
      * конец
      16. описание действий для ветки
         * если (k < 10)
            * переход к 2
         * иначе
            * переход к 17
         * конец
      17. описание действий для ветки
         * обработка ошибок
         * ВЫХОД
      * конец
      61. описание действий для ветки
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
           получаем значение n
         * переход к 3
      62. описание действий для ветки
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
         * переход к 4
      * конец
      63. описание действий для ветки
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
         * переход к 4
      64. описание действий для ветки
         * загрузка параметров
         * вызов процедуры-обработчика
         * обработка ответа процедуры обработчика
         * переход к 4
      * конец
   * конец цикла-силуэта   
   * выход
КОНЕЦ АЛГОРИТМА

4) Предполагается, что для таблицы-силуэта ЛСП может быть двумерной, причем
стандартный цикл-силуэт будет рассматриваться как таблица-силуэт с одной
строкой.
Пример двумерной ЛСП для вышеприведенного алгоритма:
Код:
ПР  1
   Д  2
   НЦ   3
      ПВ  1  4    СВ  2  6 
         Д   5       П  61  7
      К
      ПВ  3        8
         ЕС        9
            П  62  10
         ИЕ        11
            П  63  12
         ИЕ        13
            П  64  14
         К
      К
      ПВ  4  15    СВ  5  17    СВ  6  19
         Д  16        Д  18        Д  20
      К
      ПВ  7  21    СВ  11  23   СВ  12  25
         Д  22        Д  24        Д  26
      К
      ПВ  13  27   СВ  14  29   СВ  15  31
         Д  28        Д  30        Д  32
                                   Д  33
      К
      ПВ  16  34         СВ  17  38
         ЕС  35             Д  39
            П  2  36        П  0  40
         ИН
            П  17  37
         К
      К
      ПВ  61  41     СВ  62  46 
         Д  42          Д  47
         Д  43          Д  48
         Д  44          Д  49
         П  3  45       П  4  50
      К
      ПВ  63  51     СВ  64  56
         Д  52          Д  57
         Д  53          Д  58
         Д  54          Д  59
         П  4  55       П  4  60
      К
   КЦ
В  61

------------------------------------
замечание от 26.07.12 11:10 :
А в пример кода ЛСП вкрались ошибки - т.к. для псевдокода по умолчанию
переход к следующей по порядку ветке мы опускаем, а во внутреннем формате
программы такие переходы должны быть. Поэтому в примере для ЛСП нужно
расставить

П Вслед НД

для веток: 1, 4, 5, 6, 7, 11, 12, 13, 14, 15
------------------------------------
Из вышеприведенного текста алгоритма 4 видно, что таблица-силуэт была
отформатирована так, что ветки с одинаковыми номерами логических строк
(в пределах одного десятка) относятся к разным визуальным строкам
таблицы-силуэта. Это было сделано для удобства отображения схемы на экране.

Кстати, из вышеприведенной ЛСП видно, что введение двумерности для ЛСП
повышает ее читабельность по сравнению с одномерной ЛСП.


5) Предполагается ввести функцию нормализации номеров веток при
редактировании ЛСП. В промежутках между нормализациями номеров веток, если
вдруг потребуется вставить новую ветку между двумя ветками или в начале
логической строки таблицы-силуэта, можно взять для этой ветки максимальный
из свободных номеров для данной логической строки - это может привести
к последовательности номеров веток для логической строки вида:
26, 21, 22, 24, 23, 25.
После нормализации ситуация будет исправлена.
Количество веток для логической строки таблицы-силуэта не должно быть
больше 9 (желательно не создавать больше 7 веток для логической строки), при
необходимости нужно прибегать к декомпозиции с использованием нижних строк
таблицы-силуэта.


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

Рассмотрим следующий пример:
Код:
(*i*)  if (wetka = 3)
       (*---                                 // начало комментариев действия
       .. описание действий для ветки
          вторая строка описания  ---*)      // конец комментариев действия
       (* какой-нибудь комментарий *)     
   (*i*)  if (n = 2)  then begin     
          (*--- * если (n = 2)   ---*)
      (*i*)  wetka := 62;
             (*--- * переход к .. ---*)
   (*i*)  end else if (n = 3) then begin 
          (*--- * иначе если (n = 3)   ---*)
      (*i*)  wetka := 63;
             (*--- * переход к .. ---*)
   (*i*)  end else if (n = 4) then begin   
          (*--- * иначе если (n = 4)   ---*)
      (*i*)  wetka := 64;
             (*--- * переход к .. ---*)
   (*i*)  end;
(*i*)  end;

Для него будет сгенерирован следующий псевдокод:
Код:
3. описание действий для ветки
   вторая строка описания
   * если (n = 2)
      * переход к 62
   * иначе если (n = 3)
      * переход к 63
   * иначе если (n = 4)
      * переход к 64
   * конец
* конец

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


7) Введение комментариев действий в ДАЛВЯЗ 2 позволит при построении
изображения схемы отображать в блоках либо только исходный код, либо
только комментарии, либо исходный код вместе с комментариями.


8 ) Предполагается возможность отображения блоков веток в стиле языка
ДРАКОН. Для таблицы-силуэта это предположительно будет выглядеть
следующим образом:
Вложение:
ts2507.JPG
ts2507.JPG [ 78.26 КБ | Просмотров: 17270 ]

Почему не как в ДМ-О2-схеме у Владислава Жаринова - я посчитал, что
будет более естественно не направлять в одну горизонтальную линию
встречные логические переходы из обратной петли силуэта и из верхней
строки схемы, а сохранить порядок переходов "вниз-вправо".


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Не, там подразумевается по-другому маленько - многоэтажный кросс обходится по принципу "направо и вниз до "земли", а после неё - на нужный уровень". Т.е. можно считать, что промежуточные горизонтали-поперечины однонаправлены (по стрелкам замыкания этажей). Собственно, это пояснялось на примере: download/file.php?id=2426&t=1.
Возможен другой синтаксис - с раздельными поперечинами. Тогда верхняя в паре для выходов одного уровня, нижняя - для входов нижележащего. Что даёт ту самую естественность. Так сделано в другом примере: http://grafit-basis.narod.ru/images/Pag ... n_curr.png.
В обоих вариантах минимизируется требуемое число линий кросса - для удобства и изображения, и чтения (навык обхода формируется автоматически, как и в языке ЕСКД-сетей - но эти варианты несколько упрощены даже по сравнению с ним, ибо графит-метод предназначен и для "нетехнарей"). В общем синтаксис разбирался в этом подпункте.
Ессно, разработчик может принять свои решения - в то же время интересны их мотивы...

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

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

6) Синтаксис внутри среды подразумевает ведение двух описаний автономной единицы ДАЛВЯЗ-модели (кстати, то, что Вы её называете "модуль" - это связано с одноимённым понятием реализуемых ЯП)? Или д.б. какое-то единое описание с "мультилингвами" для отдельных элементов?
И ещё - в принципе ведь охранять выбор ветви в ЦС (как эмуляции ЦД по КомПас-типу) можно не только сравнением номера - но любым логвыражением (и не обязательно от чисел-скаляров). Как пример здесь: download/file.php?id=3255&mode=view - ветви дейкстрала выбираем по элементам множества, трактуемым сами по себе как булевы переменные. Очевидно, автоматически подставить как охрану ветви произвольную переменную (из числа употребляемых в "подвальных" присваиваниях) тоже можно? А в перспективе - реализовать форму конструирования охран из величин программы?

5) Сответственно нормализация именно номеров веток будет не так актуальна.

4) А что, если реализовать полноценное двумерное структурирование кода на базе ЛСП? И тогда не делать отдельно "полуторамерный" текст с простыми интендациями - а отображать всегда единый текст как "схему со снятой графикой" - или в другом понимании, как ЛСП с расшифровкой операторов и строгим упорядочением вертикалей в смысле Ермакова-Жигуненко? Можно опционально показывать там и Ваши псевдографические разграфки ЛСП-столбцов... а также включать свёртку линейных участков (до каких-то номеров, как у Вас, или как-то иначе)...

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

2) По этому тексту см. сказанное для 4).
Понятно, что следует решать вопрос с отображением текста достаточно произвольной ширины. Тут многое будет зависеть от того, будет ли выбран текстовый или графический режим вывода. Видимо, надо всё-таки остановиться на графическом.

1) Хотелось бы, чтобы слова для человека писались бы всегда полностью. Кстати, и для транслятора с ТЯП ведь это требуется... так зачем же ещё вариант написания того же самого?.. только реализацию усложняет...
Впрочем, можно предположить мотив - чтобы ЛСП в текущем варианте м.б. жёстко форматировать с постоянной шириной столбца. Однако в связи с 4) это должно стать неактуальным.

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

А в общем мысли по-прежнему интересны. Удачи!


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

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

Раз у Владислава порядок разбора вопросов был обратный, то я не буду его менять

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

ссылки на другие документы - сейчас есть ссылки на htm-файлы, хотя возможно и достаточно корявые:
---------------- из файла конфигурации ------------------------
; ссылка на записи htm-файлов (здесь N модуля - это N htm-файла):
; _>2#10 - это ссылка на запись c именем "i.10" 2-го htm-файла
-------------

"4) А что, если реализовать полноценное двумерное структурирование кода на базе ЛСП? И тогда не делать отдельно полуторамерный текст ..."

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

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

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


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

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


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

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


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

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