OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 11 Декабрь, 2019 17:22

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




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Cхематические таблицы
СообщениеДобавлено: Четверг, 21 Ноябрь, 2013 17:13 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Интересная (и мощная) концепция - "схематические таблицы" (schematic tables), как развитие метода "таблицы решений":

- обзорная статья;
- публикация от автора Jonathan Edwards (обращаю внимание, что все рисунки в конце документа, рекомендую с них и начать ознакомление);
- видео;
- прототип некой IDE;
- сайт автора (где представлены и другие идеи в области программирования).

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

- в одной таблице, как в замкнутом контуре, агрегируются все варианты входов и результатов исследуемой части вычислительной модели. Т.е. то, что в обычных ЯП разнесено в if/switch, да и pattern matching, а также отражаются и образуемые варианты при полиморфизме (!) (виртуальные вызовы методов или перегрузки функций и т.п., формируемые через классы/интерфейсы/миксины/классы типов/протоколы и т.д.);

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

- полноценные принципы декомпозиции, структурности и т.д.;

- таблица компонуется автоматически (нет ручного рисования), наполнение м.б. сформировано на основе текстового кода (программного, декларативных описаний), и проработана логика непосредственной правки таблицы, на базе атомарных действий с возможностью транзакционной записи. Теоретически возможна оперативная связь: текст <-> таблица. И при наличии семантически развитой среды возможен контроль состава вариантов решений, его автоматическое формирование, в т.ч. и авторазмещение в таблице, контроль типов данных и т.д.;

- хороший потенциал для эргономичного представления, особенно в рамках интерактивной работы и режимов отладки;

- и др.

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

На всякий случай, немного материалов по таблицам решений:

- википедия, где также приведены примеры программной реализации: здесь и здесь;
- книга Хамби Э. "Программирование таблиц решений";
- обсуждались на этом форуме, например, здесь.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Пятница, 22 Ноябрь, 2013 13:40 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9164
Откуда: Россия, Орёл
Вообще, табличное представление, как нечто среднее между графикой и текстом, интересная вещь...

Конкретно эти таблички что-то мне показались гибридом таблиц решений и Р-схем Вельбицкого ))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 27 Ноябрь, 2013 15:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Было бы ещё интересно мнение - могут быть полезными в связи с этим ЛСП-представления Дмитрия_ВБ? Ну например как они показаны на его иллюстрациях (можно найти тут: http://forum.oberoncore.ru/viewtopic.php?p=83972#p83972 - что-то постов от автора, подробнее описывающих, не нашёл). Какие обнаруживаются у них возможности и ограничения, что можно улучшить?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 04 Декабрь, 2013 15:12 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Илья Ермаков писал(а):
Конкретно эти таблички что-то мне показались гибридом таблиц решений и Р-схем Вельбицкого ))

Да-да, именно так. Особенно, если присмотреться к Р-схемам (отсюда):
Вложение:
r_sdl_tbl.PNG
r_sdl_tbl.PNG [ 71.12 КБ | Просмотров: 8944 ]

где:
Цитата:
...с - алгоритм управления лифтом 20-этажного здания, записанный на языке спецификаций SDL+; d - алгоритм управления лифтом 20-этажного здания, записанный в соответствии с ГОСТ 19.005-85 или ISO 8631Н; е - таблица решений, записанная в соответствии с ГОСТ 19.005-85 (ISO 8631Н)

т.е. лишний раз подчёркивается компактность Р-схем по сравнению с блок-схемными решениями и эргономичное сочетание Р-схем рядом с таблицами (да и сами таблицы можно задать через Р-нотацию, плюс и деревья и т.д.). А если глянуть на такую картинку:
Вложение:
tbl_r.PNG
tbl_r.PNG [ 34.8 КБ | Просмотров: 8944 ]

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

По своей сути схематические таблицы близки к функциональным схемам, например, как здесь (если я правильно пониманию тамошний "хаос" :) ). По сравнению с типовыми таблицами решений есть достоинства и недостатки. Вот примеры классических таблиц решений (извлечено из книги Хамби Э. "Программирование таблиц решений"):
Вложение:
tbl_dec.PNG
tbl_dec.PNG [ 533.29 КБ | Просмотров: 8944 ]

Или таблицы как действия:
Вложение:
tbl_act.PNG
tbl_act.PNG [ 663.84 КБ | Просмотров: 8944 ]

Говоря современным языком, таблицы решений - это DSL, и именно предметно-ориентированные. Имеется особенность:
Вложение:
tbl_probl.PNG
tbl_probl.PNG [ 316.16 КБ | Просмотров: 8944 ]

(на счёт одной большой таблицы - в самой же книге даны методики для разделения таблиц на "модули"). Так вот, вроде как, схематические таблицы и есть более совершенный формат таблиц, который имеет универсальный характер, если так можно выразиться, применим для широкого круга вычислений. Но обратная сторона медали - дополнительная сложность для восприятия из-за наличия вписанных функциональных схем (фактически, ещё один уровень измерения внутри таблицы). Поэтому вряд ли можно говорить о всеохватывающем способе разработки только через таблицы. Но для ряда случаев такие таблицы весьма полезны. Например, построение агрегатной модели вычислений для анализа (а в идеале, не помешает разработка в две стороны "текст <-> таблицы", да плюс схемы). В презентации от автора есть хороший показательный пример, когда выстраиваются вычисления через декомпозицию на базе ООП-классов, и схематическая таблица отражает, в частности, конечную картину для полиморфного метода, после какого-то варианта сборки приложения/конфигурации. Структура классов:
Вложение:
fig22.PNG
fig22.PNG [ 71.15 КБ | Просмотров: 8944 ]

Реализация метода (в документе в качестве примера представлен возможный путь разработки, где таблица дополняется новыми вариантами, и в рисунках к публикации показаны ряд последовательных этапов, а вот конечный вариант таблицы указан неполным. С целью демонстрации интерактивных возможностей якобы включено ограничение для отображения вариантов для конкретного класса (предикат поэтому выделен жёлтым). Я добавил справа и отключенный вариант, мысленно необходимо провести недостающие линии, что несложно):
Вложение:
fig26_magic.PNG
fig26_magic.PNG [ 51.49 КБ | Просмотров: 8944 ]

В общем, имхо, Р-схемы + "Р-таблицы" - неплохой симбиоз, плюс желателен и "табличный" исходный код.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 04 Декабрь, 2013 15:22 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
И, кстати, кроме схематичных таблиц у автора есть и другие неплохие решения (всё на сайте):

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

- Example Centric Programming: док - первый шаг, где делается попытка организовать программирование через примеры. Без наглядных примеров тяжело формировать абстракции, выявлять закономерности, находить аналогии и т.д. Цель: организовать процесс разработки так, чтобы формирование исходного кода, отладка, тестирование, рефакторинг, REPL были сразу в одном флаконе - это одновременный процесс. В любой момент можно запустить расчёт вычислений (пример), зафиксировать результаты (в т.ч. внести в историю, их сравнивать, и т.д.), фиксировать возникающие ошибки/проблемы, указывать неопределенные вычисления (незавершенный исходный код) и система запросит значения для них, т.е. мы постепенно выстраиваем код, через поиск правильного решения, с непрерывными экспериментами. Одним словом, обобщены принципы продвинутой лисп-машины;

- Synthetic Trees: демо, док - некий семантический редактор. Цель: максимальная простота и "example centric programming". Данные и вычисления задаются в виде деревьев, внешний вид поближе к привычному текстовому представлению (автор осторожно акцентирует внимание на том, что реальная практика на сегодня такова: масштабы ПО, созданного с помощью текстовых языков и любых иных альтернатив - не соизмеримы), причём вычисления отражаются так, чтобы показать, что происходит в стэке. Основное редактирование программы выполняется через мышь (копирование или драг с дропом), есть понятие ссылок и связывания (что даёт возможность осуществлять переименование объектов с минимум затрат), и др. (лично для меня, деревья - не лучший вариант, плюс не всё гладко с эргономикой);

- Schematic Tables - представленные здесь схематические таблицы. Видимо, дальнейшее развитие "adaptive conditionals" из мыслей для схематического редактора, как попытка объединить деревья вычислений с таблицами решений, плюс и "example ..." не забыто;

- Coherence: демо, док - свой взгляд на реактивное программирование для упрощения алгоритмизации интерактивных и реагирующих систем, как дальнейшее обдумывание "action"-ов из семантического редактора. Реакции на изменения состояний задаются декларативно, система автоматически выстраивает согласованные действия для наката изменений, причём зависимости разруливаются во время runtime, с поддержкой транзакций и откатов изменений при неуспехе. Напоминает Animotron;

- Type as subtext: демо - использование идеи "example..." для системы типизации для языка а-ля сегодняшний мэйнстрим. Вместо явного декларирования имён типов используются только значения по умолчанию, плюс принцип прототипной типизации (полиморфизм и указание ограничений);

- Synchronously Updateable Views - пока только указано, что ведутся эксперименты с новой семантикой изменения состояний. Видимо, дальнейшее развитие идей Coherence. В этой области есть неплохо отработанные техники, например, Identity and State в clojure. М.б. увидим что-то новое, причём именно для "synchronously".

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

- "example driven development" (по аналогии с "test driven development"). Ещё в качестве примера можно глянуть на проект Light Table, где закладываются схожие принципы (кроме организации рабочего места по мотивам Code Bubbles), правда пока не так широко, кроме мгновенных "REPL-ов" нужен и их анализ (хотя если разработка на базе clojure, как в прототипе, то ограничений нет для реализации чего угодно под себя);

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 04 Декабрь, 2013 15:29 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Владислав Жаринов писал(а):
Было бы ещё интересно мнение - могут быть полезными в связи с этим ЛСП-представления Дмитрия_ВБ?

"3D Р-схемы" (отсюда):
Вложение:
R-3D.PNG
R-3D.PNG [ 13.29 КБ | Просмотров: 8941 ]

Речь о том, что в Р-технологии схемы (или модули) строятся иерархически согласно уровню моделирования - от общего описания, через формальные модели до конкретной реализации, и не всегда между этими уровнями возможно отобразить явную линию как конкретную частную связь - вот ещё один повод задействовать 3D. А для связей через декомпозицию отношения можно отразить, в т.ч., и явными линиями (плюс и иерархия):
Вложение:
r_ierarh.PNG
r_ierarh.PNG [ 41.84 КБ | Просмотров: 8941 ]

Но с другой стороны, дракон-схемы, в основном, более громоздки, чем Р-схемы и такие вот схематические таблицы. И представление 3D-диаграмм в перспективной проекции, как здесь - это реальная попытка уместить хотя бы две схемы поближе друг к другу. Для полноты картины можно задействовать и "горизонтальный" 3D примерно по таким мотивам:
Вложение:
Vista_Flip_3d.png
Vista_Flip_3d.png [ 207.48 КБ | Просмотров: 8941 ]

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 04 Декабрь, 2013 15:44 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Владислав Жаринов писал(а):
Какие обнаруживаются у них возможности и ограничения, что можно улучшить?

Здесь нужно говорить не столь в адрес конкретных решений от Дмитрия_ВБ, а в контексте этой темы: Схемы в описании программ. Вот здесь сообщение А.С. Усова на счёт языков для системного моделирования. Выделю ключевое:

А.С. Усов писал(а):
... Для схем на UML,
наоборот, характерно огромное количество разных типов элементов (едва ли не
каждый элемент схемы имеет уникальный тип/класс), и большое разнообразие свя­
зей. Такое положение дел не является специфичным для программирования, это
следствие низкой культуры проектирования, которая, хочется надеяться, со време­
нем повысится.
...
Основная цель этого сообщения состояла в том, чтобы показать, что
1. На любом уровне системы, применяемые языковые средства, имеют одну и ту
же семантическую основу: элементы и связи;
2. В различных областях человеческой деятельности применяются схожие гра­
фические описания систем, и данная однородность языковых средств не слу­
чайна, а исходит из семантики систем;
3. Повышение уровней системы приводит к одинаковым изменениям в языковых
средствах, независимо от области применения систем.
4. Требования к языковым средствам достаточно просты от функциональных на
исполнительских уровнях до логических на уровнях управления и целеполага­
ния, что, конечно, тоже не случайно.

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

* маршрутная — такая, что схема есть устремлённый (аранжируемый, сводимый) граф, планарный (без пересечений при укладке на плоскости) либо нет;
* древовидная —такая, что схема есть дерево, каждая ветвь которого м.б. ребром или маршрутной подсхемой с разветвлением/соединением их через ОС-узлы, а также, возможно, «прошивкой» дерева и/или сращением двух и более деревьев;
* сетевая — такой, что схема есть конечное множество вершин с конечными чис­лами входов и выходов, причём входы и выходы м.б. либо связаны попарно (при­надлежа в паре одной или разным вершинам), либо не связаны (временно присо­единяясь к вершинам-туннелям).

Предполагается, что в этом составе можно представить любые практически тре­буемые схемы.
...
С учётом сказанного здесь, можно конкретизировать. Так, в ДАЛВЯЗ фактически определены "ордер-блок-схемы" как разновидность структур маршрутного класса.
Целесообразные ограничения возможны и для структур древовидного класса.

Можно предложить и общие ограничения порядка. Например, такие:

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

В Р-нотации все вопросы уже отработаны. Объединив Р-схемы (плюс Р-методологию в целом) с "Р-таблицами" (таблицы решений + схематические), мы получим "new UML", с новым качественным "уровнем культуры проектирования" (хотя всё это уже было в прошлом). Конкурировать с подобным "Р-стэком" проблематично, в т.ч. и в плане реализации методики построения схем, сделать процесс "клепания" диаграмм таким же лёгким, быстрым и интуитивно понятным, как и работа с текстом или таблицами. Без потенциала для "поточного конвейера" о "мэйнстриме" вряд ли можно говорить. Хотя, например, в области "блок-схемных" решений попалась на глаза такая штука: cloudextend.com, где имеется графический DSL:
Вложение:
sales_force.PNG
sales_force.PNG [ 80.19 КБ | Просмотров: 8940 ]

Напоминает InteloGraf, только ещё проще. Клепай себе как Mind Maps, думая только над прикладной проблемой, вся укладка автоматом без головоломок и гаданий с лианами и т.д. (даже циклы заданы как концевые переходы, кружочек со стрелкой). В какой-то мере, это некий шаг навстречу к "Р-блокам".

Но лично я предпочту Р-схемы + таблицы (и "Р-текст"). Они обеспечивают не только однородность моделей для всех уровней системы, но и однородность всего рабочего окружения. Если взглянуть на картинку ниже (отсюда), то вполне легко представить вместо связанных "кодо-кусочков" зависимые "Р-кусочки", которые не нарушат "табличную" гармонию всего пространства (фактически, будет тот же текст, подкреплённый линиями):
Вложение:
light-full.png
light-full.png [ 97.38 КБ | Просмотров: 8940 ]

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

Как-то так.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Четверг, 05 Декабрь, 2013 14:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
PSV100 в viewtopic.php?p=84206#p84206 писал(а):
Владислав Жаринов писал(а):
Было бы ещё интересно мнение - могут быть полезными в связи с этим ЛСП-представления Дмитрия_ВБ?

"3D Р-схемы" (отсюда):
Вложение:
R-3D.PNG

Речь о том, что в Р-технологии схемы (или модули) строятся иерархически согласно уровню моделирования - от общего описания, через формальные модели до конкретной реализации, и не всегда между этими уровнями возможно отобразить явную линию как конкретную частную связь - вот ещё один повод задействовать 3D. ...
Вот помнил же при обзоре объёмных решений, что есть ещё что-то основополагающее... Насчёт схем в описании программ там по возможности отвечу. А насчёт таблиц - "третья проблема" Хамби, похоже, о том, что они прямо ложатся хорошо только на нелинейные структуры Дейкстры... Ну и ещё: Усов также говорил и о поддержке видоизменяемости кода вплоть до момента востребования при исполнении: http://forum.oberoncore.ru/viewtopic.php?p=69216#p69216. Вы не об этом?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:28 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Владислав Жаринов писал(а):
...
Ну и ещё: Усов также говорил и о поддержке видоизменяемости кода вплоть до момента востребования при исполнении: viewtopic.php?p=69216#p69216. Вы не об этом?

Можно и об этом. Оставим в сторонке "ручные" решения, т.е. через "низкоуровневое" манипулирование указателями на функции, лямбдами, делегатами и т.п. Возможность "динамического ООП" встречается в динамических языках, таких как Phyton, Ruby и др. Но не очень-то "системно" (фактически, прямая правка метаданных классов и их экземпляров-объектов). В области, например, Lua можно найти более организованные решения для гибкого ООП, где нет типичной базовой ограничивающей классовости. Есть альтернативы и в области "статических, нативных" языков. Например, Felix - скриптовый ML-подобный язык, со строгой статической типизацией, который на выходе даёт эффективный С++-код. У него удачная объектная система - гибкое и мощное прототипное ООП, которое даёт возможность наследоваться не только от типа (класса), но и от конкретного экземпляра-объекта, с возможностью (необязательной) переопределения или расширения структуры объекта и состава операций, в т.ч. возможно и "подмешивание" объектов (не только наследование, полиморфизм). Через стандартные средства вполне ясно организуется динамическая "замена VMT", т.е. переход на новый согласованный набор операций. Есть также понимание "интерфейсов", которое не требует обязательной модификации кода объектов для их реализации, т.е. есть возможность для обобщения и построения абстракций уже после создания кода, описывающего объекты. При этом рядом существуют "классы", но это классы операций, как классы типов в хаскеле (здесь, здесь) - перегрузка функций по типам (не объектам), всё строго статично, нет никаких динамических виртуальных вызовов.
В общем, имхо, именно такой должна быть модель ООП в мэйнстриме, а не то, что сейчас...

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

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

Поэтому, ещё раз акцентирую внимание на том, что у представленных здесь схематичных таблиц есть неплохое свойство -- возможность отражения агрегатной модели вычислений. Ещё раз выкладываю рисунок, где некая ф-ция имеет варианты реализации в зависимости от типа входного аргумента (при этом в исходном коде эта ф-ция может быть определена дважды: у объекта типа Magic и объекта типа Melee, имеющих общего типа-предка Attack), плюс в этой таблице выделен явный столбец для "assert" (и "true" для безусловных исходов), что актуально при использовании верификации или ручных "assert"-ов (этого столбца нет в доке-презентации):
Вложение:
tbl_assert.PNG
tbl_assert.PNG [ 73.19 КБ | Просмотров: 8746 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:32 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Кстати, вспомнилось насчёт близости Р-схем и таблиц решений. Кроме таблиц есть и деревья решений (отсюда):
Вложение:
tree_dec.PNG
tree_dec.PNG [ 19.61 КБ | Просмотров: 8746 ]

Выразить дерево в виде Р-схемы приемлемо. Но с учётом:
Цитата:
Обычно ДР используется при малом числе действий и когда не все комбинации условий возможны, а ТР - при большом числе действий и когда возможно большинство комбинаций условий.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Четверг, 19 Декабрь, 2013 19:38 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
И вспомнилась ещё одна модификация таблиц решений - древняя "японская машина теорий" (правда, вместо форта - фортран )) ): "Moriya Shinji, Hiramatsu Keiji. Table Language and its Conversion to Computer Programs: A Proposal of TwoDimensional Programming Language". Нашёл эту публикацию на каком-то японском сайте, исходную ссылку потерял, доступ был публичным, поэтому выкладываю её здесь:
Вложение:
IPSJ-MGN130106.pdf [781.19 КБ]
Скачиваний: 202

Это "алгоритмические таблицы". Ниже выдержка, где видна вся суть (остальное в статье, фактически, одни иероглифы):
Вложение:
tbl_algo.PNG
tbl_algo.PNG [ 209.86 КБ | Просмотров: 8746 ]

Каждый столбец - "правило" алгоритма (R - rule), вверху все условия (C - condition), которые встречаются на этом пути (указаны в алгоритмической последовательности), ниже последовательность всех действий (A - action), исполняемые согласно результатам условий. Если взглянуть на таблицу решений в предыдущем сообщении (рядом с деревом), то можно заметить, что для действий вместо "Х" указываются номера последовательности. Вроде такой вариант гибче, но может усложнить чтение, и, например, в той же таблице для правила "4" последовательность задана как "2, 1", что соответствует "D4, D3", и это не сразу заметно.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Вторник, 24 Декабрь, 2013 20:31 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Сделал конкретный примерчик схем и таблиц, как обобщение изложенного здесь и в теме про "Схемы в описании программ".

В посте выше была представлена схематическая таблица, на счёт "агрегатного" алгоритма. Раскроем суть подробнее.

Пусть имеются два типа данных: Magic и Melee, обобщённые под общим типом Attack (реализованных по средствам классов, trait-ов и т.п., не важно как именно). Для каждого типа определена функция "power" (в данном случае реализации ф-ций просты, возвращают константы). А также заданы и соответствующие функции "damage" в двух вариантах (здесь уже чуть сложнее вычисления). Ставится задача показать обобщённый алгоритм ф-ции "damage" как одновременное отражение всех вариантов вычислений, определенных в системе.

Ниже рисунок, где определены:

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

- реализация ф-ции "damage" в виде:

* алгоритмической таблицы
* схематической таблицы в стиле Р-схем
* исходный схематической таблицы (для сопоставления).

Примечание. Не рассматривается оптимальность алгоритмов (более подробные обобщения и пр.), также есть и алгоритмические огрехи, например, встречается анализ результата вычислений, где включаются "<= 0 и >= 1", но не ясно, чего делать между 0 и 1. В общем, всё подогнано под уже имеющийся рисунок исходной схематической таблицы (также нет дополнительных подписей, но, вроде, и так понятно, что где):
Вложение:
agr_schems.PNG
agr_schems.PNG [ 145.08 КБ | Просмотров: 8679 ]

С Р-схемами всё должно быть ясно. Алгоритмическая таблица содержит:

* в верхней части - входные аргументы функции;
* середина - собраны все условия из "тела" ф-ции;
* ниже - содержательное тело алгоритма
* завершает таблицу - выходные результаты

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

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

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

Конечно, схемы и таблицы оформлены отвратительно из-за отсутствия инструментария. Даже "древние рукописи" и то более наглядны, компактны, удобны:
Вложение:
r_tbl.PNG
r_tbl.PNG [ 34.7 КБ | Просмотров: 8679 ]

На рисунке выше есть примечательные элементы:

- верхняя схемка (спецификация данных) и содержательная схема - очень похожи, и в то же время сразу отличаются в соответствие со своим типом;
- используются "комментарии", которые также можно втыкать и в таблицы;
- ниже пример записи таблицы (решения) через сами Р-схемы.

До кучи, ещё примерчики, лишний раз демонстрирующие, что Р-схемы применимы и для алгоритмов, и для процессов, и для данных, и т.д.:
Вложение:
r_data.PNG
r_data.PNG [ 79.12 КБ | Просмотров: 8679 ]


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

На счёт обработки ошибок. В примере ниже используется парадигма "conditions and restarts" ("условия и перезапуск"), популярные в "лиспах". Похожа на типовую модель вида "try-except/catch/finally", но с принципиальными отличиями: при обработке ошибок не выполняется раскрутка стека (с соответствующей потерей контекста), и принятие решения о применении предопределенной политики восстановления вычислений выносится наверх (выше уровни).

Модифицируем предыдущий пример. Пусть имеется некая ф-ция "set_damage", принимающая список объектов типа Attack, плюс и другие данные. Эта функция теперь устанавливает свойство "damage", имеющееся у объектов, по алгоритмам выше. Псевдокод:
Код:
type Attack = {damage: float}
type Magic = extend Attack {...}
type Melee = extend Attack {...}

error InvalidVal(float) = SetVal(float) | Ignore

set_damage: ([Attack]!, Bool, Int) => !  with InvalidVal

set_damage = (attacks!, surprise, defense) -> loop'(attacks)
    where loop' = ([ ]) -> !
                  ([attack!, ...atks]) ~>
                        case attack of
                             Magic  =>  power = 5
                             Melee  =>  power = 4

                        effectiveness = (power * 3) if surprise else (power * 2)

                        case attack of
                             Magic  =>  set_magic(attack, effectiveness)
                             Melee  =>  attack.damage = effectiveness / defense * 2

                        loop'(atks)

          set_magic = (attack!, effectiveness) ->
                            damage = effectiveness - defense
                            case of
                                 | damage <= 0  =>  attack.damage = 0
                                 | damage >= 1  =>  attack.damage = damage
                                 | _            =>
                                                    try fail(InvalidVal damage) handle
                                                        SetVal(x)  =>  attack.damage = x
                                                        Ignore     =>  _


do ->
    attacks = [...]
    try set_damage(attacks, true, 234.78) with
        InvalidVal(x)  =>  SetVal(x*0.66 - x)

Ф-ция "set_damage" принимает изменяемый (!) список объектов, не возвращает значения. В спецификации указано, что ф-ция "отправляет" сигнал об ошибке вида "InvalidVal". В реализации видно, что ошибка возникает как раз при неопределенности в анализе результатов. В примере вызова ф-ции указано, что необходимо применить политику "SetVal" (другая политика - для игнорирования значения, и соответствующий объект не обновляется). Само тело функции реализовано через цикл в виде рекурсивного вызова встроенной функции, причём строго "хвостовой".

Итак, также из таблицы удалим вертикальные линии, которые создают эффект "циклограммы" (имеющийся и в исходных таблицах), и остальной мусор, возьмём "Р-стандарт" (предикаты - вверху, действия - внизу), в общем, приведём всё к классическому аскетичному Р-виду:
Вложение:
set_damage.PNG
set_damage.PNG [ 29.22 КБ | Просмотров: 8679 ]

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


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

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

В общем, всё однородно, полиморфно, декомпозиция и агрегатные модели, "немногое о многом"...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 25 Декабрь, 2013 19:35 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Здорово! А вопрос всё тот же: в чём смысл узлов схем (элементов структур) в каждом конкретном типе структуры? и как/где его предлагается определять?
Что можно всё определить - не вопрос. Исходя из двойственности родов - просто указали, что сущностям предметики будут соответствовать не элементы знаковой системы, а её связи... И будут тебе и синтдиаграммы, и потоки управления, и структуры предметов, и тракты исполнителей... и всё 2-го рода... И в схемах, и в эквивалентном тексте... что и продемонстрировано... причём насколько не раскрыт смысл узлов в схематических записях, настолько же и в текстовых...
Вопрос не праздный именно в связи с замечанием, что ОС-узлов лучше бы поменьше. И вот почему. Говоря словами Усова, "связи между своими элементами устанавливает система". А когда у нас элементы системы (по смыслу предметики) решено представить связями языка моделирования системы - то получается, как в сетевых графиках... что надо именно "прописать" в предложении языка явно все варианты связности элементов.
Т.е. если для семантики сетей техопераций-"работ", где должны произойти расщепления/слияния "точек управления" - везде надо "всобачить" НПД-узлы аналитического/синтетического типа... все цепочки техопераций между ними задублировать... А уж как там с циклами - это вон обсуждали уже по Романовскому... а по Элмаграби ваще такое получается...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 25 Декабрь, 2013 20:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Поправка к своему предыдущему сообщению. В Р-схематической таблице есть описки: не указан предикат для первого столбца тела функции, рядом во 2-м и 3-м столбцах действия указаны как предикаты. Исправленная версия:
Вложение:
set_damage2.PNG
set_damage2.PNG [ 30.68 КБ | Просмотров: 8639 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Среда, 25 Декабрь, 2013 20:32 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
В общем это всё-таки надо понимать как автоматную структуру (узлы-состояния, дуги-переходы)? И, как и у "автоматчиков", дуги размечаем условиями активации перехода + действиями при активации?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Пятница, 27 Декабрь, 2013 19:20 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
"Усы, лапы и хвост" - вот и все автоматы :) , т.е. "if"-ы, "case"-ы, "switch"-и. Эта та же Р-схема или Дракон-диаграмма, но в табличной форме.

Вся таблица делится на три вертикальных части:

* слева - аргументы функции;
* далее тело ф-ции;
* последний столбец - результат ф-ции;

Аргументы и результат могут отсутствовать. В секции входных аргументов каждый столбец отражает всю информацию об одном аргументе. Вверху, как заголовок -- дуга, где предикат сопоставляется с определением аргумента, и может быть связанное действие:
Вложение:
arg_header.PNG
arg_header.PNG [ 2.11 КБ | Просмотров: 8602 ]

что может означать:
Код:
procedure set_damage(var attacks: List[Attacks]; const surprise: Bool; const defense: Int);
begin
...
end

Ниже в столбце могут быть (необязательно) указаны все возможные значения аргумента. В этом случае далее в теле функции все действия будут указаны именно в контексте этого значения:
Вложение:
arg_val.PNG
arg_val.PNG [ 3.08 КБ | Просмотров: 8602 ]

В секции для тела функции каждый столбец выражает только одно действие. Формируется конвейер операций из столбцов, слева направо. В заголовке столбца -- дуга, где предикат отражает смысл действия, к примеру, задаёт имя переменной. Ниже в ячейках могут быть указаны действия (под дугами), предикаты (над дугами). Предикат отражает результат того, что указано выше в ячейках - или действия, или заголовка столбца. И предикат, и действие сопоставляются всегда с тем, что указано выше и слева в таблице:
Вложение:
pred_act.PNG
pred_act.PNG [ 7.62 КБ | Просмотров: 8602 ]

Здесь выражено, что переменная "attack" может иметь два значения: "Magic" и "Melee", затем переменная "power" в соответствие с этими значениями может принимать два варианта значения: "5" и "4". Таким образом, столбец всегда отражает только одно действие, но вариантов может быть много. И если глянуть влево рисунка, то обращаем внимание, что вся эта пляска из-за того, что первый аргумент ф-ции "attacks" является не пустым списком. Всё это в результате может быть транслировано так:
Код:
procedure set_damage(var attacks: List[Attacks]; const surprise: Bool; const defense: Int);
begin
    if attacks.NotEmpty then
    begin
        attack := attacks.GetHeader();
        atks := attacks.GetTail();

        if attack = Magic then
            power := 5
        else
        if attacks = Melee then
            power := 4;
        ...
    end;
    ...
end

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

Дуга действия может быть продлена до конца таблицы - до результата ф-ции. В то же время, чтобы не лепить длинных палок, например, для аргумента ф-ции м.б. указана дуга, что означает продвижение ещё до конвейера, т.е. немедленный выход из функции (при этом в таблице в соответствующей строке нет никаких действий):
Вложение:
arg_exit.PNG
arg_exit.PNG [ 9.62 КБ | Просмотров: 8602 ]

Транслируем:
Код:
procedure set_damage(var attacks: List[Attacks]; const surprise: Bool; const defense: Int);
begin
    if attacks.NotEmpty then
    begin
        attack := attacks.GetHeader();
        atks := attacks.GetTail();
        ...
    end
    else exit;
end

Действия могут быть связанными, выражая функциональные отношения:
Вложение:
act_link.PNG
act_link.PNG [ 11.23 КБ | Просмотров: 8602 ]

Здесь "effectiveness" вычисляется как умножение "power" на значение из предыдущего шага, которое, в свою очередь, зависит от аргумента ф-ции "surprise":
Код:
procedure set_damage(var attacks: List[Attacks]; const surprise: Bool; const defense: Int);
begin
    if attacks.NotEmpty then
    begin
        attack := attacks.GetHeader();
        atks := attacks.GetTail();

        if attack = Magic then
            power := 5
        else
        if attacks = Melee then
            power := 4;
       
        if surprise then
            tmp := 3
        else
            tmp := 2;

        effectiveness := power * tmp;

        ...
    end
    else exit;
end

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

И действия, и предикаты могут иметь несколько вариантов. Правила обработки предикатов такие же, как и в Р-схемах - сверху вниз, т.е. так выражается последовательность для "if"-ов. Действия могут сопоставляться только с предикатами слева (в заголовке ничего нет), могут формировать цепочки операций. Масштаб рассмотрения действий и связей -- произвольный:
Вложение:
act_var.PNG
act_var.PNG [ 11.36 КБ | Просмотров: 8602 ]

Циклы выражаются через спецдугу. Если дуга никак не подписана -- переход на начало ф-ции. Рекомендуется по возможности быть функционально однородным, и циклы формировать через рекурсивные вызовы (к тому же, меньше вопросов как организовывать "while"-ы с "repeat"-ами). В исходном примере рядом с таблицей был текстовый код, который, фактически, есть набор функций, где имеется и рекурсия. Точно также можно отобразить одновременно весь набор таблиц-функций и исследовать процесс (алгоритм).
Для наглядности можно нужный столбец, как в теле ф-ции, так и в аргументах (или даже все столбцы-аргументы), "накрыть" спец-дугой:
Вложение:
recurs.PNG
recurs.PNG [ 9.24 КБ | Просмотров: 8602 ]

Обратная дуга -- против конвейера, отражает вылеты из функции. Семантика м.б. разная. Например, для аргументов ф-ции:
Код:
      arg1: int | arg2     !! var1
    <-----------|--------->!!--------->   ...
      < 0       | string   !!
                |          !!
    ...

Транслируем:
Код:
function some_func(arg1: int; arg2: string): any_type;
begin
    if arg1 < 0 then
        raise Exception ("arg1 < 0");
    ...
end;

Или "assert" для конкретного значения аргумента:
Код:
      arg1      | arg2     !! var1
    ----------->|--------->!!--------->   ...
      int       | string   !!
                |          !!
    ...
      1         |          !!  ...
    ...         |          !!

      -1        |          !!  ...
    <-----------|          !!
                |          !!
    ...   

Эквивалентно:
Код:
function some_func(arg1: int; arg2: string): any_type;
begin
    case arg1 of
        1 :   ...;

        ...

        -1 : raise Exception ("arg1 = -1");
    ...
    end;

    ...
end;

Точно также могут быть заданы условия для любого столбца (в заголовке) -- и для действий, и для результата ф-ции. Внутри столбца-операции проверочные условия могут быть заданы как предикаты без связанных действий:
Код:
    | var1    |
    |-------->|
    |   ....  |
    |         |
    |   < 0   |
    |<--------|
    |         |
    |   ...   |

Код:
function some_func(arg1: int; arg2: string): any_type;
begin
    ...
    if var1 < 0 then
        raise Exception ("var1 < 0");   
    ...
end;

Если указать действие прямо под предикатом:
Код:
    | var1    |
    |-------->|
    |   ....  |
    |         |
    |   < 0   |
    |<--------|
    |  Беда!  |
    |         |
    |   ...   |

Код:
function some_func(arg1: int; arg2: string): any_type;
begin
    ...
    if var1 < 0 then
        raise Exception ("Беда!");   
    ...
end;

В таблице могут быть столбцы вида "try - except/finally" с соответствующей обработкой.

В исходном примере применялась семантика "сигналы и продолжение" (рядом был поясняющий код):
Вложение:
signal.PNG
signal.PNG [ 9.16 КБ | Просмотров: 8602 ]

Если не сработают "if"-ы: "_ <= 0" и "_ >= 1", то будет "отправлен" сигнал "InvalidVal(_)" (вместе со значением вычислений). Если где-то сверху в стеке вызовов ф-ций нет обработчика сигнала или сигнал не обработан -- вылет, иначе -- предикаты ниже и последующие действия отражают анализ полученных указаний и их применение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Пятница, 27 Декабрь, 2013 19:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Все примеры выше отражали семантику потенциального языка программирования. Если в заначке имеется качественный ЯП, где через систему типов будет контроль заполняемости схем/таблиц (учтены ли все варианты, расставлены ли "assert"-ы, и т.д.), да плюс "автоматизация" -- очень хорошо. Схемы и таблицы можно нагружать любой семантикой, как алгоритмикой для человека, так и "автоматикой" системотехники. Более того, Р-схемы -- это графический функциональный язык программирования и моделирования общего назначения, где схемы и таблицы -- всего лишь функции, и всё является функцией. Отсюда, через функции можно определить модель данных, состояний, переходов, сообщений, взаимодействия, пролог-деклараций и т.д. и т.п. Вводя аргументы ф-ций можем формировать варианты чего-то моделируемого, проводить анализ, выявлять общее и отмечать разницу, редуцировать новые варианты на базе имеющихся, и опять же на результаты смотреть как на функцию.

Насчёт структурных узлов и сетей разного рода. В Р-схемах нет встроенного понятия ни узла, ни сети. Даже на спецвершину нужно смотреть как на функцию, которой в качестве аргументов подаются блоки или дуга-функция:
Код:
       
    (&)------------->+
      |  proc1       |
      |              |
      |              |
      |------------->|
      |  proc2       |
      |              |
      |  NeedProc3   |
      |------------->|
         proc3

Что может быть интерпретировано так:
Код:
    ...
    begin
        spawn( proc1 );
        spawn( proc2 );
        if NeedProc3 then
            spawn( proc3 );
    end;
    ...

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

Или же возможна такая семантика:
Код:
       
    (fork)------------->(join)
         |  proc1       |
         |              |
         |              |
         |------------->|
         |  proc2       |
         |              |
         |              |
         |------------->|
            proc3

Транслируем:
Код:
    ...
    begin
        f' := fork(proc1, proc2, proc3);
        result := join(f');
    end;
    ...

Функция может быть любой:
Код:
          condition
(пример)------------->(/пример)
          action

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

Поэтому, всё решает смысл, загружаемый в функции, "как яхту назовёшь, так она и поплывёт...".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Пятница, 27 Декабрь, 2013 19:30 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Владислав Жаринов писал(а):
...Сделал связи предметики связями языка, сопоставил им правила существования (зависящие от состояния системы вместе со средой) - и всё... а какие там из связей осуществятся "на опыте", это реализация модели (конкретная система) решит... а если нам надо это узнать "до опыта", то накатаем имитореализацию (модельного исполнителя модели :)) и прогоним на ней наше предложение (получив историю как конкретную подструктуру Крипке, "трассу" на этой структуре)... Вот можно такое сделать в Р-схемах?..

Можно и нужно. Автор оригинальных схемтаблиц выдвигает концепцию (а точнее, обобщает) "Example-Driven Developmen", например, здесь:
Вложение:
EDD.PNG
EDD.PNG [ 739.38 КБ | Просмотров: 8600 ]

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

При этом Р-схемам/таблицам не помешает и интерактивная отладка, примерно так (отсюда):
Вложение:
debug.PNG
debug.PNG [ 58.23 КБ | Просмотров: 8600 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Пятница, 27 Декабрь, 2013 19:32 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Итого. Р-схемы -- это графические функции, которые позволяют вместо выдумывания символики заниматься непосредственно самим делом, самой сутью, формируя аксиомы, выстраивая теории, выдвигая гипотезы... Каждая функция может быть представлена как:

* формальный и неформализованный текст;
* Р-схема;
* схематическая таблица;
* алгоритмическая таблица (сборник "правил" функции).

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Cхематические таблицы
СообщениеДобавлено: Вторник, 31 Декабрь, 2013 00:13 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 389
Ещё один пример функции "set_damage". Здесь имеются "вылеты" из функции, в виде "exception". Псевдокод:
Код:
function power(attack: Attack): Int;
begin
    case attack of
         Magic: result := 5;
         Melee: result := 4;
    end;
end;

function set_damage(var attacks: List[Attack]; const surprise: Bool; const defense: Int): void;
begin
    if defense < 0 then
        raise Exception("defense < 0");

    while (attacks =:= [attack, ...atks]) do
    begin
        if surprise then
            tmp := 3
        else
            tmp := 2;

        effectiveness := power(attack) * tmp;
        if effectiveness <= 0 then
            raise Exception("effectiveness <= 0");

        case attack of
             Magic:
                    begin
                        tmp' := effectiveness - defense;
                        if tmp' <= 0 then
                            attack.damage := 0
                        else tmp' >= 1 then
                            attack.damage := tmp'
                        else
                            raise Exception(" tmp' > 0 and tmp' < 1 ");
                    end;

             Melee: attack.damage := effectiveness / defense * 2;
        end;
    end;   
end

Р-схема:
Вложение:
set_damage3.PNG
set_damage3.PNG [ 26.74 КБ | Просмотров: 8522 ]

Схематическая таблица (здесь функция "power" встроена в таблицу, специально нет никаких цветовых выделений и пр.):
Вложение:
set_dam_schm.PNG
set_dam_schm.PNG [ 27.16 КБ | Просмотров: 8522 ]

Алгоритмическая таблица:
Вложение:
set_dam_algo.PNG
set_dam_algo.PNG [ 31.71 КБ | Просмотров: 8522 ]


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

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


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

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


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

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