DRAKON.SU :: Просмотр темы - Когнитивная слепота, Дракон, цикл Дейкстры. О зашоренности

TAU
Заголовок сообщения: Re: О зашоренности
Добавлено: Среда, 25 Апрель, 2012 20:00

Peter Almazov писал(а):
Если им дать простой текст из нескольких абзацев, то они, как минимум, сочтут его ненаглядным

Да, ненаглядным. А вы что же - будете называть черное белым (набор из сотен мелких значков на экране - наглядным)?

Peter Almazov писал(а):
Если все это растянуть по вертикали

Согласитесь, что это - уже заметное преобразование.

Peter Almazov писал(а):
обвести в рамочку и соединить их вертикальными линиями

Здесь уже получается принципиально иной объект, нежели текст, разве нет?

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

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

...

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

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

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

Владислав Жаринов пишет:
У Вас, Дмитрий, в примере производящий язык для схемы - псевдокод. Т.е. адекватный по строгости. Там и алгоритм уже "вытащен", и состав объектов, и "репертуар" действий (проверять величины на равенство, делать что-нибудь и бить баклуши).

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

2. ФАКТОР(время) - <время отрисовки Дракон-схемы в редакторе> / <время набора программы в текстовом редакторе>

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

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

в этом сообщении

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

...
Видно, что среда рассматривалась с экономических позиций - т.е. как любой инструмент (точнее, как спецоснастка для техпроцесса визуализации знаний на станке типа "Интел-ИБМ-МС|Wine"

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

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

...
Кстати, создатели Дракона не задумывались над обратной задачей: генерировать дракон-схемы по коду на ЯВУ - в качестве иллюстрации при головоломной передаче управления? Обычные блок-схемы генерятся - я сам такую программку опробовал. Иллюстративные возможности Дракона не грех использовать, в отличие от попыток программировать непосредственно на Драконе. Эта задача проще, так как блок-схема не обязана быть однозначно понятной компьютеру. Лишь бы человек разобрался.

Так что надо ещё в текстовом виде "скрестить"... ну хотя бы с О-07...

Получится нечто вроде языка для структурного редактора В. Лаптева.

... Но собственно визуальная часть в Драконе гораздо беднее по возможностям и менее эргономичная, чем, например, в PureBuilder.

Сергей Прохоренко писал(а):

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

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

...
Только боже упаси реализовывать преобразование "иллюстрация на Драконе" -> "исходный код, в т.ч. в структурном редакторе", при котором пару раз пересаженная лиана приведет к полной кастрюле GOTO-лапши в исходном коде.

Автор:	Владимир Паронджанов [ Среда, 25 Апрель, 2012 09:09 ]
Заголовок сообщения:	Когнитивная слепота, Дракон, цикл Дейкстры. О зашоренности
На сайте OberonCore есть форум "О зашоренности". Хвост этого форума по инициативе Петра Алмазова посвящен Дракону. Даю ссылку на сообщение Петра Алмазова и последующие viewtopic.php?p=72346#p72346 В дискуссии представлены разные точки зрения.

Автор:	Дмитрий_ВБ [ Среда, 25 Апрель, 2012 09:51 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Петр был остроумен - ему оставался только 1 шаг до фразы: "Сторонники Дракона - когнитивные кроты". По поводу моей фразы: (+ на идеи в области создания визуального интерфейса, которые в настоящий момент еще не сформулированы или только начинают проходить свою экспериментальную обкатку в каких-нибудь почти никому не известных сейчас инновационных компьютерных фирмах) Трудно сказать, каким будет интерфейс с компьютером лет через 5. Возможны варианты от сравнительно локальных изменений типа touch-screen, параллельной работы с 2-мя мышами, введения и стандартизации новых, не используемых сейчас элементов визуального интерфейса до интерфейса с использованием жестов, движений глаз, голоса и даже (чего только не может быть в будущем!) при помощи мыслеуправления. Я считаю, что в таких условиях вопрос стандартизации текстовой формы техноязыка, в том числе для записи декларативных знаний, по-прежнему остается актуальным.

Автор:	Владислав Жаринов [ Среда, 25 Апрель, 2012 10:15 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Ну, если снять излишнюю грубость формулировок - то можно извлечь из сказанного вполне практическое замечание. Что пользоваться императивными (декларативными и иными частными представлениями) нужно не просто, чтобы перевести ЕЯ-текст в схему и на этом остановиться. Но чтобы переходить на более глубокие уровни формализации - математический и далее. Но что-то подобное и делал, скажем, Эдуард... так что всех и в любых случаях обвинять в "когнитивной слепоте" не следует... А в данном случае, есно, такой шаг сделал-то уже Степан и сейчас...

Автор:	Дмитрий_ВБ [ Вторник, 01 Май, 2012 10:53 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Решил прокомментировать следующее замечание TAU: Цитата: TAU Заголовок сообщения: Re: О зашоренности Добавлено: Среда, 25 Апрель, 2012 20:00 Peter Almazov писал(а): Если им дать простой текст из нескольких абзацев, то они, как минимум, сочтут его ненаглядным Да, ненаглядным. А вы что же - будете называть черное белым (набор из сотен мелких значков на экране - наглядным)? Peter Almazov писал(а): Если все это растянуть по вертикали Согласитесь, что это - уже заметное преобразование. Peter Almazov писал(а): обвести в рамочку и соединить их вертикальными линиями Здесь уже получается принципиально иной объект, нежели текст, разве нет? Удалось случайно выделить день для просмотрщика и вот что получилось (конечно недоделка, но это сейчас не важно): Код: АЛГОРИТМ.3 заголовок * цикл-силуэт * если ветка = 1 * делаем что-нибудь РИС.12 * ветка := 2 qqqqqqqqqqqqqq wwwwwwwwwwwwwwww eeeeeeeeeeeee * иначе если ветка = 2 эта ветка очень важна для понимания алгоритма ! * бъем баклуши dddddddddddddddddd aaaaaaaaaaaaaa * ветка := 3 * иначе если ветка = 3 * бъем баклуши * ветка := 4 * иначе если ветка = 4 * бъем баклуши * ветка := 5 * иначе если ветка = 5 * бъем баклуши * ветка := 0 * конец * конец цикла-силуэта * выход КОНЕЦ АЛГОРИТМА Вложение: dal2view.JPG [ 77.31 КБ \| Просмотров: 18645 ]

Автор:	Владислав Жаринов [ Четверг, 03 Май, 2012 08:13 ]
Заголовок сообщения:	Когнитивная слепота, зашоренность и формализация :)
А чем Вам замечание TAU не нравится (шутка )? Как раз Ваш пример показывает всё то же - "когнитивная слепота" не в том, что в принципе пытаются получать граф-схему (в частности, императивную на техноязыке) по тексту. А в том, что при этом игнорируют тот факт, что эта схема уже есть представление обычно более формальное. Об этом хорошо сказал в своё время А. Куликов: ORG100H в http://live.cnews.ru/games/index.php?sh ... 894&st=26# писал(а): ... Многим ДРАКОН не нравится, потому что на нем трудно описать мысли запутавшегося в задаче. ДРАКОН требует искать условие, отвечать, и строить правильное ветвление логики. Но наши легионеры привыкли из логической структуры делать слипшиеся спагетти. Как же это понравится человеку, который как и всякий бурбакист, гордится, что у него ни одного геометрического чертежа, а всё получилось манипуляциями с символами. И при этом через три месяца он не может пояснить того, что же хотел сказать, когда писал этот кусок кода. ... Ряд вещей в том же посте вызвали, скажем так, вопросы - посему пришлось разобрать здесь: viewtopic.php?p=66483#p66483. Но вот с этим согласен. И это как раз ещё к непренебрежимости уровнями процесса формализации/моделирования (чем у нас, как обнаружилось по любезному указанию В.Д., и академики, по-видимому, пренебрегать пытаются - см. здесь: viewtopic.php?p=69519#p69519 )... Среди которых есть уровни информатически строгие - рассчитанные на исполнителя типа "языковая машина", деятельность которого есть алгоритмический процесс. Конкретно - Куликов прямо указывает, что само приложение техноязыка как системы записи импер-части отчуждаемого знания, более формальной, чем естественный язык, уже выводит сочинителя на более строгую формализацию. Где надо "вытащить из текста алгоритм/систему взаимодействующих алгоритмов". А одновременно - также "вытащить" систему определений объектов (как абстрактных/"конкретных" типов). И определение исполнителя алгоритмов над объектами... Т.е., то, что у Кауфмана в Гл. 3 - абстракции операций, данных и связывания для планирования деятельности исполнителя. Образующие целостный базис. И требующие, между прочим, не игнорировать текст как разметку схемы, а наложить на него некие требования строгости, адекватные строгости, налагаемой формализованным графом как основой схемы... А когда дело ограничивается этим: Peter Almazov в viewtopic.php?p=72346#p72346 писал(а): ... все это растянуть по вертикали, каждый абзац обвести в рамочку и соединить их вертикальными линиями,... - то степень "незапутанности" начинает определяться текстом вершин (и рёбер, если предусмотрена их содержательная разметка). И может получиться, что цель формально-графового представления, сформулированная здесь: Илья Ермаков в viewtopic.php?p=72439#p72439 писал(а): ... Вы не учитываете один важный фактор эволюции инженерных инструментов: для задач, которые стали обыденными, есть стремление к снижению многообразия способов выразить идею. Способов записать "простой текст из нескольких абзацев" - огромное количество (не говоря про число способов его понять). В своих "боях" с паттернами циклами Вы игнорируете точно тот же фактор. Общая теория - это прекрасно, потом же на практике для типичных случаев целесообразно уменьшать многообразие способов выразить мысль. - не будет по факту достигнута. Потому что многообразие способов понять граф из кусков такого текста сохранится... У Вас, Дмитрий, в примере производящий язык для схемы - псевдокод. Т.е. адекватный по строгости. Там и алгоритм уже "вытащен", и состав объектов, и "репертуар" действий (проверять величины на равенство, делать что-нибудь и бить баклуши). Здесь многообразие уже сведено к трактовке конкретным исполнителем в конкретной ситуации действия "делать что-нибудь". Очевидным исполнителем является человек. Если мы полагаемся на его здравый смысл - то такое многобразие допустимо. Иначе следует формализовать более строго смысл уже этого действия. Что, очевидно, приведёт к частной модели его как алгопроцесса... В общем, сочинитель д.б. незашорен на том, чтобы просто "разнести неформальный текст по вершинам". А д.б. готов сразу идти дальше по уровням формализации. Тогда "когнитивной слепоты" не будет. И, между прочим, выявится то самое, о чём говорил Куликов - что сама попытка "разнести" у нормально мыслящего человека выявит направления уточнения представления о предмете... Между прочим, как раз через подведение его под систему тех самых паттернов. Взятых либо поодиночке, либо, если ограничиться импер-частью отчуждаемого знания - в композиции цепочек/циклов (даже без ветвлений - согласно теореме Бёма-Джакопини ). А среди одиночных паттернов ведущим будет как раз цикл Дейкстры (ну и Ваш ЦС-эквивалент, который снова использован в примере). М.б. в силу сходного понимания Пётр Алмазов и не сделал шаг до высказанного Вами утверждения... А указал некие условия, при коих "любитель Дракона" "демонстрирует пример когнитивной слепоты". И тут сказанное, что: Дмитрий_ВБ в viewtopic.php?p=72370#p72370 писал(а): ... в таких условиях вопрос стандартизации текстовой формы техноязыка, в том числе для записи декларативных знаний, по-прежнему остается актуальным. - важно. Тока стандартов-то д.б. семейство - как минимум из классов "родных" и "программных". Не говоря уже о том, что формы записи деклар-части - это вообще отдельный род графических языков. Описания на которых, конечно, связываются с техноязыковыми... И за ними тоже должны свои паттерны стоять... У меня были сформированы конкретные предлжения - но всегда интереснее познакомиться с конструктивом от других...

DRAKON.SU https://forum.drakon.su/

Когнитивная слепота, Дракон, цикл Дейкстры. О зашоренности https://forum.drakon.su/viewtopic.php?f=62&t=3948	Страница 1 из 2

Автор:	Дмитрий_ВБ [ Четверг, 03 Май, 2012 08:57 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Цитата: Владислав Жаринов пишет: У Вас, Дмитрий, в примере производящий язык для схемы - псевдокод. Т.е. адекватный по строгости. Там и алгоритм уже "вытащен", и состав объектов, и "репертуар" действий (проверять величины на равенство, делать что-нибудь и бить баклуши). Псевдокод у меня в примере приведен для простоты. Меня, естественно, интересует более практический аспект: Основная мысль Владимира Даниеловича: Визуальное и эргономичное представление алгоритма в форме силуэта дает возможность охватить алгоритм одним взглядом и провести визуальную оценку правильности его структуры, что позволяет выявить часть ошибок, возможно содержащихся в этом алгоритме. Техноязык - это вещь предназначенная для практического использования. Владимир Даниелович показал возможность его применения на примере конкретного технического проекта - разработки управляющих программ для бортовых вычислительных комплексов ракетной техники. А теперь идет поиск наиболее эффективного способа применения техноязыка при использовании его для решения широкой области задач из императивной области знаний. Я считаю, что пока наиболее эффективный способ применения техноязыка еще не найден.

Автор:	Дмитрий Дагаев [ Четверг, 03 Май, 2012 10:16 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Peter Almazov писал(а): Если им дать простой текст из нескольких абзацев, то они, как минимум, сочтут его ненаглядным, а то и вовсе непонятным. Если все это растянуть по вертикали, каждый абзац обвести в рамочку и соединить их вертикальными линиями, то они начинают восторгаться. Хорошая критика. В качестве конструктивного зерна предлагаю извлечь: 1. ФАКТОР(байт) = <число байт текста в Дракон-редакторе> / <число байт инвариантной/сгенеренной программы> 2. ФАКТОР(время) - <время отрисовки Дракон-схемы в редакторе> / <время набора программы в текстовом редакторе> можно брать методики оценки Дж.Раскина по временам работы графического интерфейса. А потом оценить редакторы и кодогенераторы.

Автор:	Ильченко Эдуард [ Четверг, 03 Май, 2012 13:21 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Дмитрий Дагаев писал(а): 2. ФАКТОР(время) - <время отрисовки Дракон-схемы в редакторе> / <время набора программы в текстовом редакторе> Я бы предложил оценивать время разработки алгоритма. Но не знаю : ) как это сделать. Поскольку дважды в одну реку не зайти ...

Автор:	Виктор О [ Четверг, 03 Май, 2012 14:25 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Ильченко Эдуард писал(а): Я бы предложил оценивать время разработки алгоритма. Но не знаю : ) как это сделать. Поскольку дважды в одну реку не зайти ... 21 студент и 4 задачи. 1. 20 студентов решают задачу 1 методом Текст. 2. 20 студентов решают задачу 2 методом Граф. 3. Разбиваем студентов на две группы по 10, уравнивая результаты по обоим методам. 4. Группа 1 решает задачу 3 методом Текст и задачу 4 методом Граф. 5. Группа 2 решает задачу 4 методом Текст и задачу 3 методом Граф. 6. Студент-психолог по своим стандартным методикам считает вашу реку. (кстати, ему это можно пустить курсовичком)

Автор:	Сергей Прохоренко [ Четверг, 03 Май, 2012 15:45 ]
Заголовок сообщения:	Re: Оценки сложности формализации
Сравнивать нужно не на специальных простых примерах, под которые заточен Дракон. Но я сильно сомневаюсь, что всё, что возможно, скажем, на C#, возможно и на Драконе с автоматической трансляцией в исполнимый код (или в целевой язык программирования). И боюсь, что за пределами самых простых операторов программирование на Драконе выродится в программирование на целевом языке программирования, только все операторы будут обводиться в рамочку и располагаться не только по вертикали, но и по горизонтали. Современные алгоритмы включают в себя гораздо более сложные вещи, чем просто передача управления от одного оператора к другому, которое можно изобразить линией на блок-схеме. Пример - присвоение значений переменной процедурного типа (только вчера увидел у сына - студента). Передача управления в этом случае происходит скрыто - на уровне ассемблера. Линией на блок-схеме это не изобразишь. Никаких специальных выразительных средств для таких операторов Дракон не имеет, и остается только обводить операторы обычного языка программирования рамочками. А оно надо? Результат сравнения на сложных примерах очевиден: набивать код в Студии заведомо быстрее, чем набивать тот же самый код, но с рамочками в доморощенном редакторе Дракона. Кстати, создатели Дракона не задумывались над обратной задачей: генерировать дракон-схемы по коду на ЯВУ - в качестве иллюстрации при головоломной передаче управления? Обычные блок-схемы генерятся - я сам такую программку опробовал. Иллюстративные возможности Дракона не грех использовать, в отличие от попыток программировать непосредственно на Драконе. Эта задача проще, так как блок-схема не обязана быть однозначно понятной компьютеру. Лишь бы человек разобрался.

Автор:	Axcel [ Четверг, 03 Май, 2012 22:06 ]
Заголовок сообщения:	Re: Текстовые и не только стандарты языков
Сергей Прохоренко писал(а): ... Но собственно визуальная часть в Драконе гораздо беднее по возможностям и менее эргономичная, чем, например, в PureBuilder. Типа анекдота. Во времена, когда компьютеры были большие и медленные, коллектив делал крутую программу, что-то не получалось, пригласили специалиста со стороны, тот пошаманил, и все заработало. На итоговом совещании местные стали доказывать, что по их схеме программа работала БЫ на сколько-то там быстрее (в те времена это было важно), на что пришлый ответил, - "если бы я делал неработающую программу, я бы сделал ее еще более быстрой"

Автор:	Сергей Прохоренко [ Пятница, 04 Май, 2012 09:05 ]
Заголовок сообщения:	Re: Текстовые и не только стандарты языков
Axcel писал(а): Сергей Прохоренко писал(а): ... Но собственно визуальная часть в Драконе гораздо беднее по возможностям и менее эргономичная, чем, например, в PureBuilder. Типа анекдота. Во времена, когда компьютеры были большие и медленные, коллектив делал крутую программу, что-то не получалось, пригласили специалиста со стороны, тот пошаманил, и все заработало. На итоговом совещании местные стали доказывать, что по их схеме программа работала БЫ на сколько-то там быстрее (в те времена это было важно), на что пришлый ответил, - "если бы я делал неработающую программу, я бы сделал ее еще более быстрой" Ерничают, когда нечего возразить по существу. Уже сейчас есть более десятка визуальных средств разработки типа Scratch, которые по своим возможностям и эргономике многократно превосходят Дракон. А то, что перспективные идеи в этом направлении еще не реализованы - это не их недостаток. От того, что Дракон реализован (кстати, далеко не полностью), ничего по большому счету не изменилось.

Автор:	Владислав Жаринов [ Пятница, 04 Май, 2012 09:53 ]
Заголовок сообщения:	Re: Об эскизной формализации неформального описания
Сергей Прохоренко писал(а): Для решения задачи преобразования "исходный код, в т.ч. в структурном редакторе" -> "иллюстрация на Драконе" можно в исходный язык программирования добавить конструкцию "комментированный блок". Тогда при указанном выше преобразовании всякие ненужные подробности исходного кода превратятся в соответствующий комментарий в рамочке, а студенткам, о которых писал В.Лаптев, станет понятен алгоритм в списанной у однокурсников лабе. Не знаю уж, как работают студентки у кого, но мне довелось поставить эксперимент, где этот фактор как раз исключился: viewtopic.php?p=40397#p40397. Результат приводил здесь. Так уж получилось, что девушки (некоторые) лучше всех справились (в т.ч. ребят). И не у кого было им списывать (кроме Паронджанова ). Почему так? Уже Валерий говорил: viewtopic.php?p=57317#p57317 - в силу образности мышления. В то же время, как можно видеть, результат "сырой". О причинах этого тоже сказано: viewtopic.php?p=64991#p64991. И выводы были сделаны - приведены здесь: viewtopic.php?p=65075#p65075 (а реализованы ещё раньше). К этому, кстати, имеет отношение и следующее Ваше замечание: Сергей Прохоренко писал(а): ... Только боже упаси реализовывать преобразование "иллюстрация на Драконе" -> "исходный код, в т.ч. в структурном редакторе", при котором пару раз пересаженная лиана приведет к полной кастрюле GOTO-лапши в исходном коде. Вполне согласен. Поэтому и предлагал только атомарный вывод - как здесь описан. Не понял, что за комментированный блок. Свёртывать можно и саму запись - как текстовую, так и граф-базированную. Впрочем, они д.б. "двумя сторонами одной медали" (т.е. вьюшками от одного файла проекта). Как, скажем, в "Ракетном дизайнере кода"... Т.о. студентки не только списывать могут... но и сделать нечто, что студентам впору списать... Главное - чтобы удобно думать было... в частности, и по форме... Замечу, что хотя к противникам ДРАКОНа не отношусь - но и против предлагаемой Вами (а также Романченко, да и Лаптев вроде задумывается) формы "дерева таблиц" ничего не имею. Такую вьюшку ведь тоже из того же проекта можно генерить (более того, она м.б. базовой структурой "программно строгих" частей проекта... а по Лаптеву - и проекта в целом)...

Страница 1 из 2	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Владислав Жаринов [ Четверг, 03 Май, 2012 09:35 ]
Заголовок сообщения:	Re: Когнитивная слепота, Дракон, цикл Дейкстры. О зашореннос
Как раз у Ильи можно найти выход на такой способ. В сказанном, что "... для задач, которые стали обыденными, есть стремление к снижению многообразия способов выразить идею". Только распространить это с "эволюции инженерных инструментов" на эволюцию предмета инженерии. И тогда получится та самая технология формализации "от эскизной к детальной", которая обсуждалась ещё в этой теме... И также уточнить, что здесь "становление обыденности" есть именно уточнение понимания предмета. В частности, и под влиянием использования более формальных инструментов. Только вот "проверка структуры" (т.е. графа схемы в отвлечении от его разметки) м.б. на первом месте, когда по определению гибридного языка синтаксис этой самой разметки строг. А то ведь структуру графа проверим - а в тексте м.б. нечто, с этой структурой перекликающееся (ибо сочинитель не позаботился о его надлежащей переработке). Хорошо, если оно просто дублирует содержание, выражаемое графом (хотя и здесь ничего хорошего - нарушается принцип "единства источника данных")... а если прямо этому противоречит?.. И получится, что мы эргономично выявляем ошибки (на графе), которых в нормально сочинённом описании (с должно формализованным текстом) и не было бы (возможно, другие появились бы - но и их надо выявлять, привлекая текст). В общем, реальные критерии "когнитивной слепоты" прежде всего в том, что: * полагают, что можно относить смысл "просто текста" (неформального до применения графовой структуризации) к схеме, полученной по этому тексту; * считают возможным ограничиться в строгой модели только одной компонентой "базиса абстракций" (напр., императивной) и игнорировать существование других (и не пытаться описать эти компоненты). Понятно, что к Вам-то это никак не относится - только что говорили о необходимости стандарта на деклар-компоненту. Как и ко многим "любителям Дракона", которые честно стремятся формализовать различные составляющие базиса или по крайней мере указывают, что это нужно, но в конкретной их работе почему-то не сделано или недоделано. В частности, из-за отсутствия подходящих средств записи оостальных абстракций базиса...

Автор:	Владислав Жаринов [ Четверг, 03 Май, 2012 16:24 ]
Заголовок сообщения:	Об эскизной формализации неформального описания
Я уже так и вижу, как в ответ кто-то из "поклонников Дракона" пишет: "а вот, например, в PureBuilder..." и далее следует какой-нибудь образец спецпропаганды... вроде разобранного здесь или здесь... А если серьёзно и сохраняя нейтральность - то Вы утверждаете всё-таки не то, что имели в виду сторонники техноязыка. И это как раз можно показать, привлекая эквивалентные текстовые языки. Т.е. нормальная визуализация - это не просто "обведение текста рамочками". Это как вначале "просто текст" перевести на более формальный язык. Скажем, ЯПУ Потопахина. В результате чего в нём появляется структура. Выраженная ключевыми словами (если мы выявляем структуру в импер-части - то маршрутными). И остальной текст становится более строгим. Потому что начинает играть роль атрибутов структурных элементов. А уже затем эту запись мы превращаем в схему. Где "рамочки и линии" не "обводят текст" (исходный - так надо понимать) - а замещают собой маршрутную лексику в ЯПУ-тексте. Просто опытный сочинитель может сразу в уме делать более более строгое представление и в виде уже схемы...