DRAKON.SU

Текущее время: Вторник, 04 Август, 2020 15:05

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




Начать новую тему Ответить на тему  [ Сообщений: 51 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
 Заголовок сообщения: Re: Дракон-схемы - на поток
СообщениеДобавлено: Суббота, 28 Август, 2010 12:19 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Драконограф писал(а):
Дмитрий_ВБ в viewtopic.php?p=50794#p50794 писал(а):
Если пометить основные действия процедуры числовыми метками, а
затем в текстовом файле расшифровать, что они означают - то это
уже будет огромный рывок в документировании программ...

Я верно понял, что смысл этих меток - номер вершины (которой в ТФАП отвечает строка её текстового определения) для ведения связей в графе? Тогда пометка д.б. автоматической.
.


К сожалению, автоматически не получается. Вот пример текста программы и соответствующего ему текстового описания БС:

if (m_ind[i].type < 3) {// прямоугольник //.14

x1 = gbs_smx + m_x_wetok[ii] + m_ind[i].gbs_x; //.15
y1 = gbs_smy + m_y_wert + m_ind[i].gbs_y;

x2 = gbs_smx + m_x_wetok[ii] + m_ind[i].gbs_x2;
y2 = gbs_smy + m_y_wert + m_ind[i].gbs_y2;

gbs_line(x1,y1,x2,y1);
gbs_line(x2,y1,x2,y2);
gbs_line(x2,y2,x1,y2);
gbs_line(x1,y2,x1,y1);

// координаты текста //.16

x1 = gbs_smx + m_x_wetok[ii] + m_ind[i].gbs_x + (gbs_chw*2);
y1 = gbs_smy + m_y_wert + m_ind[i].gbs_y + (gbs_chdy / 2);
}

..14 |- 17
Это прямоугольник ?

..15
Вывод прямоугольника

..16 | 20
Задать координаты текста прямоугольника

..17
...

Метки должен расставлять программист, хорошо понимающий смысл написанного им программного модуля.
Иногда метка соответствует одной строке кода, а иногда нескольким.
Компьютеры (в открытом доступе - а у военных, наших или американских, может уже и терминаторы имеются)
до этого пока еще не доросли.

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


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

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

ЧФ (FR) (значок) - чтение файла
ЗП (FW) (значок) - запись файла
Э (ScR) (значок) - вывод на экран

специфические:

МФ (MF) (значок) - работа с вещественными данными
МИ (MI) (значок) - работа с целыми данными
Стр (Str) (значок) - обработка строк

Ну и каждый волен вводить свои текстоглифы и значки - это как список сокращений в начале документа

Драконограф писал(а):
Т.е. нужно комплексно решать вопросы визуального программирования даже для одного прогязыка. И это-то при внимательном рассмотрении не так просто - см. вопросы, затронутые в этом сообщении.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Август, 2010 12:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
Если бы была мощная, эффективная (...) и полностью отлаженная VIDE ДРАКОН, генерирующая полноценный код для всех распространенных ЯПВУ, я бы и сам такой средой пользовался. Но и.с.Дракон Г.Н.Тышова пока на такое определение не тянет,

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Дракон-схемы - на поток
СообщениеДобавлено: Суббота, 28 Август, 2010 12:48 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
Драконограф писал(а):
Дмитрий_ВБ в viewtopic.php?p=50794#p50794 писал(а):
Если пометить основные действия процедуры числовыми метками, а
затем в текстовом файле расшифровать, что они означают - то это
уже будет огромный рывок в документировании программ...

Я верно понял, что смысл этих меток - номер вершины (которой в ТФАП отвечает строка её текстового определения) для ведения связей в графе? Тогда пометка д.б. автоматической.
.


К сожалению, автоматически не получается.

Метки должен расставлять программист, хорошо понимающий смысл написанного им программного модуля.
Иногда метка соответствует одной строке кода, а иногда нескольким.
Компьютеры (в открытом доступе - а у военных, наших или американских, может уже и терминаторы имеются)
до этого пока еще не доросли.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Сентябрь, 2010 23:42 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
ab 2.15

Новые возможности:

1) Вывод блок-схемы в сжатом виде
2) добавлена кнопка Н - нормализация индексов действий
выбранной блок-схемы с шагом нормализации, заданным
в ab.cfg .

Вывод блок-схемы в сжатом виде

В ab 2.14 предусмотрено 2 формата вывода блок-схемы: для
фонта 1 и для фонта 2.
Вывод для Фонта 1 показывает блок-схему с таким качеством,
с каким она будет сохранена в bmp-файле.
Вывод для фонта 2 позволяет отформатировать блок-схему
так, чтобы все ее вертикали по высоте помещались бы в
полноэкранном окне АВ (при разрешении экрана 1280*1024).
Но ни один из этих форматов вывода не позволяет увидеть
в полноэкранном окне АВ всю блок-схему целиком или хотя бы
большую ее часть.
Для решения этой задачи и предназначен формат вывода блок-
схемы в сжатом виде (режим сжатия).
В режиме сжатия во всех блоках выводятся только первые 4
символа текста этого блока или сокращение для текста
этого блока максимум из 4-х букв, если оно задано.
Сокращение для текста блока задается в индексной строке
этого блока между индексом действия и описателями
переходов, например:

..17 (ЧКФГ) |+ 21

.т.е. если чтение конфигурации, то переход к действию 21.

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


Нормализация индексов действий выбранной блок-схемы

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

if (a > b) {//.10

c = d+e; //.20

a = c+d: //.30

... //.40
...


Буду рад вашим замечаниям и предложениям.

Вложение:
ab.JPG
ab.JPG [ 124.69 КБ | Просмотров: 7823 ]


Вложение:
ab_215.rar [461.87 КБ]
Скачиваний: 207


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Сентябрь, 2010 19:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
ab 2.15

Новые возможности:
...
Буду рад вашим замечаниям и предложениям.

Вложение:
ab.JPG


Вложение:
ab_215.rar


Драконограф в viewtopic.php?p=50779#p50779 писал(а):
Кстати, интересно Ваше мнение, как языки типа Оберона со структурированием программы на модули представлять удобно для человека в виде граф-схем - там ведь всё не сводится к алгоритмам - процедуры группируются в модули, модули образуют сеть, импортируют друг друга, экспортируют величины своих заголовочных типов...

А возможное решение довольно простое - см. в этом сообщении.
ПК-схема кроме всего прочего заменяет UML-диаграмму размещения, а аналогичная схема из вставок показывает дракон-модель (или любую систему процедур, напр. написанных на ВЯЗБС) в сжатом виде (без развёртки в сеть с повторами неоднократно входящих процедур).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 05 Сентябрь, 2010 13:38 

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

Что касается перекодировки силуэт <-> структурный код программы:

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 07 Сентябрь, 2010 04:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ писал(а):
Что касается перекодировки силуэт <-> структурный код программы:

(именно структурный, а не с помощью goto и его имитации при помощи
конструкций "цикл - если",...

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


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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Драконограф писал(а):
А какие ещё способы представления структурных конструкций для явно-адресного исполнителя Вы видите?

Кроме упомянутого мной "while if" еще "while case", а еше можно в цикле вызывать
процедуру с if-ами, в которую условие передается как параметр-переменная.
Возможно, есть еще варианты, но сейчас лень напрягать голову на эту тему.

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

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

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

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


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ в viewtopic.php?p=50795#p50795 писал(а):
Ильченко Эдуард писал(а):
Зачем вообще лезть в текст псевдокода, отображающего визуальный алгоритм?


Ну, некоторым программистам это нравится.



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

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

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

P.P.S. Ещё нашёл наглядный пример разметки текста в "Современном компьютере"
Вложение:
Комментарий к файлу: Иллюстрация принципа форматирования текста и языка описания форматов.
Терри_Виноград-Работа_с_ЕЯ-извл(разметка_текста).djvu [23.61 КБ]
Скачиваний: 221
Здесь визуализация доведена до показа предметного (битового) представления. Дальше уже некуда - разве что перейти на физический уровень и показать состояния ячеек памяти текста, наподобие того, как это сделано в заключительной статье того же "Современного компьютера" :)

Эдуард Ильченко в viewtopic.php?p=50795#p50795 писал(а):
Имхо, для качественного документирования ПО достаточно текстового описания для чего программа предназначена, как она это делает, ДРАКОН-схемы с необходимой степенью детализации (и лучше вообще человеческим языком) и самого текста программы с небольшими комментариями по ходу кода. Конечно, нужно ещё всякое другое, типа структуры классов, описание объектов, возможных событий, используемых протоколов, конфигурации железа, взаимодействия с интерфейсом и т.д. и т.п., но это уже мелочи : ) Вот если бы из всего этого некий программный продукт создавал документацию (кстати и ГОСТы всякие есть по оформлению доков) было бы замечательно. А если ещё и бесплатно, так и вообще сказка : )

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О стандарте ВЯЗБС
СообщениеДобавлено: Суббота, 11 Сентябрь, 2010 19:03 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ в viewtopic.php?p=50937#p50937 писал(а):
Кстати, в фортрановские времена некоторые программировали следующим образом: разрезали лист на горизонтальные
полоски, нумеровали их и писали на них команды. А на другом листе при помощи карандаша и ластика набрасывали блок-схему, где у блоков вместо названий были номера.
Похоже на вывод в режиме сжатия, хотя в АВ есть одно существенное отличие - сама программа пишется структурным стилем, а метки нужны для документирования процедуры.

А, ну это как в реальном стандарте описания логики процессов СМК, который я приводил для примера в этом сообщении... в этом же примере описана и судьба этого стандарта при реальном применении сочинителями :) У Вас же как раз эргономичный исходный вариант - всё в схеме.

Не совсем понял - "метки нужны для документирования процедуры" - это что значит?

Дмитрий_ВБ в viewtopic.php?p=50987#p50987 писал(а):
Если программа генерации исходного кода из визуальной схемы преобразует ее в текст с переходами, то казалось бы, чего волноваться - надо только заполнить окошки для ввода немаршрутных операторов процедуры, а все переходы отследит
умная программа.

Кстати, идея - оформить вершины ВЯЗБС-схемы "под диалоговые окошки" - где номер вершины и название (операция) пишется в заголовке окна, а внутри канвы идут строки операндов с полями имени и значения в каждой. На месте строки состояния окна - ссылка на номер следующей вершины (для условной - пара ссылок - по главной и побочной вертикалям); от поля ссылки и отходит ребро (на побочную вертикаль - с изломом влево); чтобы было совсем по правилам шампур-метода - ссылки от условия ставим "этажами", причём на побочную вершину - поверх ссылки на главную, делая от её строки отвод сразу влево.
Можно и слегка варьировать форму канвы по бокам для разных типов вершин - скажем, если для действия как в обычном боксе бока - это вертикальные прямые, то для заголовка/конца округлые, для имени/адреса ветки - полутрапециями-"крылышками" с соответственной ориентацией скошенных сторон, а для условия - "угловыми скобками"; в Вашей графике других подразделений не предполагается, но ещё я бы вставку всё-таки отличал удвоением прямых линий боков...
Можно и комментарии сделать иконами, как в дракон-алфавите - полагая, что содержимому выделяется отдельная строка (абзац) исхтекста, а если языком текста это не предусмотрено - то что содержимое приписывается, допустим, после текста следующего оператора.


Последний раз редактировалось Владислав Жаринов Воскресенье, 12 Сентябрь, 2010 04:56, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 11 Сентябрь, 2010 19:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Дмитрий_ВБ в viewtopic.php?p=50987#p50987 писал(а):
Кроме упомянутого мной "while if" еще "while case", а еше можно в цикле вызывать процедуру с if-ами, в которую условие передается как параметр-переменная.
Возможно, есть еще варианты, но сейчас лень напрягать голову на эту тему.

Да, пожалуй, хватит :) ... вон в Promela "while if" (циклом Дейкстры) и простым case с вариантами-логвырами (при единственном варианте естественно эквивалентном "if") обошлись.

Дмитрий_ВБ в viewtopic.php?p=50987#p50987 писал(а):
Но структурное программирование придумали именно потому, что при изменениях текста процедуры структурные конструкции оказываются более защищенными от внесения ошибок при редактировании программы в текстовом редакторе, чем процедура с тотальным использованием goto вместо структурных конструкций.
...
немного попользовавшись этим генератором исходного кода, некоторые могут захотеть отказаться от него, оставив себе только текст своей собственной программы. А в ней уже будет полно трудноотслеживаемых в текстовом редакторе goto или имитирующих его конструкций.

Не совсем понял - ведь в структурных текстовых импер-конструкциях точки слияния записываются ("имитируются") заменителями БП (end-if, end-case, od, wend и т.п.). И отслеживать их можно практически только по отступам - что тоже непросто.


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

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


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

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


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

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