OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 18:54

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




Начать новую тему Ответить на тему  [ Сообщений: 135 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7
Автор Сообщение
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 17:34 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Далее, почему важно многомерное и полное описание:
А. Седов писал(а):
>> 4.0. Одной из идей, все поставившей на ноги, стало представление о
>>пространстве состояний решаемой задачи. Вкратце это вот что. В мире нет
>>ничего "твердого", мир - это ансамбль взаимодействующих динамических процессов,
>
> Понятно - та же формула сущего, единая теория поля и т.д.
> Но основная задача как раз в том и состоит, чтобы отсечь незначительные процессы
> и сосредоточиться на определяющих, а не вводить в расчет учет местоположения
> планет на небосводе.

Приведу ответ Вашего воображаемого оппонента, который Вам заявит:

-- Хорошо, не будем учитывать положение планет на небосводе. А почему?
Вот до Чижевского не учитывали наличие пятен на Солнце. Оказалось, они
ДИКТУЮТ глобальные земные процессы. Как Вам такой оборот? Кто будет
решать, ЧТО ИМЕННО Вы собираетесь учесть в своей модели? Ландау с Лифшицем?
А если у меня есть основания считать, что в моей ситуации их теория
врет или неприменима? Прикажете переписывать единую теорию поля? А это вовсе
и не нужно В МОЕЙ уникальной системе представлений, называемой астрологией.
Я МОДЕЛИРУЮ ТО, ЧТО ХОЧУ, И ТАК, КАК ХОЧУ! Не нужно навязывать мне фитюлек,
получивших статус икон. Я знаю только одно: в реальном мире все связано со
всем, и характер этих связей НЕВОЗМОЖНО описать раз и навсегда какой бы то
ни было теорией, хотя бы и со штампом "Одобрямс!" самого Господа Бога!
Дайте мне МЕХАНИЗМ ЗАПИСИ моих идей, а уж ЧТО ИМЕННО я буду записывать --
это мое личное дело. Может, мои теории Дьявол визирует...

Боюсь, что вот это крыть будет просто нечем... При всем моем уважении к
единой теории поля и формуле сущего :-))...

...

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

Про сопромат: см. выше. И насчет молекулярного уровня: в связи с достижением
ракетами и самолетами сверхзвуковых скоростей (и соответствующих нагрузок
на конструкции) возник ряд эффектов текучести обычно "твердых" материалов,
для учета которых ПРИШЛОСЬ-ТАКИ лезть на молекулярный уровень, чтобы ПОПРАВИТЬ
формулы сопромата. Весь вопрос в том, КТО ИСПОЛЬЗУЕТ соотвествующую модель:
студент, вожделеющий тройки на зачете, или исследователь, занимающийся теорией
прочности. Во втором случае просто не станут слушать предложений про учебник
сопромата, поскольку любой специалист с ходу перечислит Вам десяток глупостей,
написанных в этом учебнике. Кстати, то же самое произойдет и в других случаях,
вне пределов любимого сопромата.

Модель (в идеале) должна учитывать ВСЕ уровни детализации представлений,
но иметь механизм выбора масштаба использования. Когда Вы крутите
винт на микроскопе, Вы просто устанавливаете видимость того, что Вам
интересно. Хорош был бы микроскоп, который позволял бы видеть только
объекты 1:100. И все! А 1:99 или 1:101 уже нельзя! ;-(

Модель -- это (в идеале) АБСТРАКТНЫЙ НАУЧНЫЙ ПРИБОР, позволяющий исследовать
явление с такой степенью глубины и детальности, как это вообще возможно.
Теории (напр., макро- и микротеории прочности) -- это регулировочные
винты сего прибора, позволяющие установить требуемые масштаб и избиратель-
ность. Состояние, в котором находятся эти "запчасти" сегодня слишком часто
напоминают результат деятельности маньяка-разрушителя, разобравшего единый
механизм и разбросавшего его детали по углам. Это состояние логического
хаоса, вполне естественного на следующее утро после "информационного взрыва".

>> 4.1. Выбирая "квант наблюдения" интересующего нас суперпроцесса (среды),
>>содержащего все остальные микропроцессы, мы имеем МНОЖЕСТВО характерных
>>НЕСОВПАДАЮЩИХ периодов стабильности для подпроцессов рассматриваемого
>>суперпроцесса, при переходе между которыми РАДИКАЛЬНО может меняться не
>>только модель отдельного микропроцесса, но и модель суперпроцесса, пред-
>
> Естественно наши простенькие модели работают в своих пределах.
> На баллистическом участке нам нужна масса и скорость материальной точки,
> при входе в атмосферу - аэродинамика изделия, при встрече с целью-
> энергитические параметры ВВ.

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

Может, пора ЗАПРЕТИТЬ подобную простоту в Уголовном кодексе (что уже частично
и сделано)? И ПОТРЕБОВАТЬ от критических по надежности систем БЕЗУСЛОВНОЙ
ЛОГИЧЕСКОЙ ПОЛНОТЫ?

Попробуйте объяснить родственникам погибших в том самолете, что "естественно,
наши простенькие модели работают в своих пределах"... Интересно, что они
Вам ответят?.. ;-((


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 17:39 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Почему именно матрицы состояний/таблицы решений:
А. Седов писал(а):
>> 4.2. Каждый микропроцесс интересует нас как набор определенных параметров.
>>Некоторые из них являются внешними для микропроцесса (параметры среды или па-
>>раметры других, связанных ЛЮБЫМ способом с данным микропроцессов), некоторые -
>>внутренние (параметры микропроцесса). Связи между ВСЕМИ параметрами микро-
>>процесса (внешними и внутренними) задаются матрицами связей, описывающими
>>правила перехода между значениями любого параметра при заданных значениях
>>всех других связанных параметров. В простейшем (и наиболее общем случае)
>>матрица связей имеет размерность алгебраического произведения всех значений
>>всех собственных параметров микропроцесса и внешних связанных параметров.
>
> Ага, многомерное пространство, где каждая переменная - орт, и по начальной
> точке и n-1 координат конечной получаем n-ую. И что здесь нового, зачем нам
> матрица. Чем плоха система n уравнений?

СОВЕРШЕННО нового в рассматриваемых методах действительно не очень много,
поскольку придется вернуться к ряду идей, составлявших альтернативы современному
программированию с начала 60-х -- конца 50-х (ДО массового использования
ЯВУ).

"Система уравнений" плоха тем, что это -- опять ЧАСТНЫЙ СЛУЧАЙ куда более
общего описания связей в терминах логических значений, через логические
матрицы связей. После школьной математики, конечно, бывает трудно представить,
что логическая матрица есть БОЛЕЕ ОБЩАЯ структура, чем составленная НА ЕЕ
ОСНОВЕ система уравнений, поскольку с последними знакомы все, а логические
матрицы встречаются в спецкурсах и нечасто. Но когда Вы вспомните, что для
решения систем уравнений все равно приходится прибегать к МАТРИЧНЫМ методам,
где "уравнения", как таковые, просто исчезают в процессе выполнения
БОЛЕЕ ОБЩИХ матричных операций, все станет на свои места.

Тем более, что решать системы уравнений для определения N-го значения,
при использовании моделей, к сожалению, приходится ОЧЕНЬ редко. По одной
причине: крайне редко такие модели задают действительно "систему уравнений"!
Получаемая "логическая матрица" есть скорее не система из N уравнений,
а формальная грамматика, конечный автомат, R-диаграмма и т.п. Идея
что-то "вычислять" по системе уравнений, полученной из грамматики
языка Cи, может оказаться очень плодотворной, если знать две вещи:
а) ЧТО вычислять, и
б) ЗАЧЕМ.

...

> Гораздо больше для этого подходит гипер-текст, как таковой
> и его проявления.
> (диаграммное представление мне тоже очень нравится).

Не могу с Вами согласиться. Гипертекст -- это ничем не ограниченный хаос
связей с неконтролируемой сложностью любого фрагмента. Диаграмма обычно еще
более бесполезна, поскольку не выражает НИЧЕГО (просто не может этого делать!),
кроме АНАЛОГИЙ реальности. Лично мне аналогии не интересны. Интереснее методы
ТОЧНОГО, ЯСНОГО, ПОЛНОГО, НЕДВУСМЫСЛЕННОГО описания САМОЙ РЕАЛЬНОСТИ.

По врожденной любознательности меня интересует ГЕНЕТИЧЕСКИЙ КОД реального
мира. Методом аналогий его не постичь.

> > плюс еще много всего, о чем в одном абзаце не напишешь. Аналогично можно
> > сделать, используя вместо Forth языки C/C++/(Object)Pascal, но тогда нужно
> > отказаться от их собственного синтаксиса, приняв, что программа есть
> > многомерная таблица из слов, а уже определения слов строятся по правилам
> > C/C++/(Object)Pascal. И т.п.
>
> Опять таблица. :((. Не понимаю.
> Может быть ... некая иерархическая структура?

Например, иерархия многомерных таблиц. Хотя -- НЕ ТОЛЬКО иерархия. С
иерархической структурностью все сравнительно просто. Но вот "боковая",
"соседская" организация объектов модели, разная степень взаимодействия
"соседей" -- это именно та область, где ООП становится ПРАКТИЧЕСКИ БЕСПОЛЕЗНЫМ,
(вместе с парадигмой иерархии), а вот парадигма МНОГОМЕРНОГО ПРОСТРАНСТВА
СОСТОЯНИЙ, где ВСЕ СВЯЗАНО СО ВСЕМ, но КАЖДУЮ связь можно отделить от
других и проанализировать независимо, прекрасно справляется с делом.
Выражается ли такое пространство состояний ИЕРАРХИЕЙ, ОТНОШЕНИЕМ СОСЕДСТВА
И ВЗАИМОВЛИЯНИЯ или НАБОРОМ НЕЗАВИСИМЫХ ПОДСИСТЕМ -- второстепенно.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 17:42 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Теперь краткое понимание сути "машины теорий":
А. Седов писал(а):
>>причудливым способом, становясь прямо противоположным текущему. Практически
>>НЕВОЗМОЖНО иметь ОДНО И ТО ЖЕ описание для каждого подпроцесса на все
>>интересующее нас время решения задачи. И здесь не поможет никакая иерархия
>>классов. Требуется для каждого "объекта" иметь БОЛЕЕ ЧЕМ ОДНО ОПИСАНИЕ
>>и свободно переходить между ними в требуемые моменты исполнения модели.
>
> Скорее здесь нужна иерархия обьектов-моделей данного изделия и экспертная
> система, определяющая какую из этих моделей задействовать в данных условиях.

Модель и есть средство для создания КОЛЛЕКЦИЙ объектов-теорий, не обязательно
иерархически связанных (но включая сюда и иерархии). Машина теорий (интер-
претатор модели) и есть "экспертная система", определяющая не только
"какую из теорий задействовать в данных условиях", но и способная сравнить
(при наличии аппаратного мультипроцессорного параллелизма) практические
последствия выбора той или иной теории (рассчитывая несколько вариантов
по нескольким альтернативным теориям одновременно). ИЗ МОДЕЛИ экспертная
система получается КОМПИЛЯЦИЕЙ (прямая задача), превратить ЭКСПЕРТНУЮ СИСТЕМУ
в модель (обратная задача) часто просто НЕВОЗМОЖНО! Экспертная система
есть вариант модели. Обратное -- неверно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Среда, 03 Октябрь, 2012 18:27 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
О возможной реализации. Собственно, мысли об этом летали ещё до того, как я здесь на форуме разместил тему про Р-схемы. Я был (и есть) в поиске гармонии между функциональным текстовым языком (как прикладной, DSL или 4GL) и его возможным графическим представлением, в частности, оценивались Р-схемы. Также есть желание подключить таблицы решений, раньше у меня о них было представление просто как о хорошей "помогалке" в ряде случаев, но вот случайно наткнулся на идеи Седова (ещё раз спасибо Алексею Донскому), которые мне "раскрыли глаза".
Почему именно в стиле а-ля "функционального". Вот пример простой таблицы решений из книги Хамби:

Вложение:
tbl1.PNG
tbl1.PNG [ 108.32 КБ | Просмотров: 12558 ]


Фактически, это обобщённая матрица значений формулы, где линейная запись свёрнута в таблицу, т.е. иная форма представления куска программы:
Код:
bonus :: Sex -> Age -> Standing -> Int
bonus Male age standing   | age > 50 && standing > 10  = 90
                          | age <= 50 && standing > 10 = 70
bonus Female age standing | age > 50 && standing > 10  = 80
...


Также через программный код могут быть заданы и такие таблицы "действий" (по Хамби):

Вложение:
tbl2.PNG
tbl2.PNG [ 537.33 КБ | Просмотров: 12558 ]


Короче говоря, таблицы решений - свёрнутая запись формул с инвариантами. "Функциональный" язык как раз близок к "МЕТОДу ФОРМАЛЬНЫХ МОДЕЛЕЙ" с "математическими" зарисовками, при этом математики там не больше школьного уровня. Есть возможность задать простой синтаксис, полегче, чем в Хаскеле, и более удобный, к тому же синтаксис гибкий, с возможностью описать предметную область, здесь были небольшие примерчики.

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

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

Если и исходные модели, и "программы" их оценки представлены как одни и те же "модули", взаимосвязанные, то это автоматом решает проблему: "даже поддержка каких-нибудь систем контроля версий не сильно коррелирует с документированным процессом поиска решения задачи.", при этом системы контроля версий поддержат вариантность проектов (т.е. также имею в виду разные варианты моделей, со своими пространствами состояний, и разные варианты их оценок/применений). Результаты моделирования и конструирования, как итоговый программный DSL-код, может быть трансформирован далее под потребности (в исходники нужного языка: С++, Java, Pascal, Asm и т.д., в байт-код или конечный бинарный, в таблицы СУБД и т.п.).

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

И как финал, цитата Седова для логического заключения:
А. Седов писал(а):
>> 5.0. Правила перехода между значениями параметров в матрице связей
>>процесса ("функции/подпрограммы" в обычном программировании или "методы" в
>>объектном) ОБЯЗАТЕЛЬНО должны иметь ДВА представления: логическое -
>>оперирующее "словесными" обозначениями значений параметра типа {горячий,
>>теплый, холодный} и числовое - оперирующее соответствующими числовыми значениями
>>(для температуры это могут быть соответственно величины {3E+5C, 42.3C, -70C}).
>
> Ну зачем нам логика - она насквозь субьективна (горячо,холодно).
> Она имеет смысл при введении субьекта в модель - зачем он нам?

Беда состоит в том, что СУБЪЕКТИВНО ВСЕ ЗНАНИЕ! В математике, правда,
открыли это недавно, но философы предупреждают нас об этом которую сотню
лет. То, что Вы увидите, зависит от того, ОТКУДА Вы на это смотрите:
от Вашей специфической точки зрения, опыта, образования, дальтонизма наконец.
Даже физика "сломалась" на принципе неопределенности, когда выяснилось,
что процесс измерения может РАДИКАЛЬНО менять картину изучаемого процесса.
А значит, т.н. "абсолютную истину" можно предполагать только по правилам
статистики, т.е. ПРОСТО НЕ ЗНАТЬ, что же точно будет в конкретно следующий
момент времени с изучаемой системой, какой именно будет, например, ее
структура из набора возможных вариантов.

Разные люди видят мир, представляют его, раскладывают по полочкам и
интерпретируют по-разному. И это -- основа т.н. "прогресса", который
обеспечивают только ОБЪЕМНЫЕ представления о мире со всех возможных сторон,
исключая догматическое невежество по принципу "этого не может быть,
потому что не может быть никогда".

Поэтому задача настоящего исследователя (аналитика, проектировщика) -- уметь
СОБИРАТЬ РАЗНЫЕ ТОЧКИ ЗРЕНИЯ, ГОНЯТЬСЯ ЗА ОТЛИЧНЫМИ ОТ ОБЩЕПРИНЯТЫХ МНЕНИЯМИ,
КОЛЛЕКЦИОНИРОВАТЬ ПОЛНОТУ ПРЕДСТАВЛЕНИЙ, а не убогий понравившийся ЛИЧНО МНЕ
прецедент. Разница между догматикой и наукой состоит в этом. В этом же
состоит и разница между знаниями и заблуждениями о своих знаниях.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 11 Октябрь, 2012 19:21 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Рэйлвэй Каген писал(а):
..попробуем поиграться триплетом "контекст, состояние, событие"
Рэйлвэй Каген писал(а):
..как должно происходить непосредственное "сочленение" процессов?
То, что получилось, широко известно в узких кругах под названием "active objects". Соответственно и проблемы будут общие.
    1. маршрутная часть между процессами д.б. исключена, поскольку представляет собой лишь одну из проекций некоторой неупомянутой сущности. Именно в силу этой особенности разные команды "описателей" имеют возможность вольготно трудиться на благо заказчика. При этом каждая из них составит правильное описание. Та команда, которая заявит, что предыдущие всё сделали не так, скорее всего не особо компетентна.
    2. каждый процесс становится просто "слушателем" и никогда не завершается.
    3. чтобы всё это работало, нужно ещё подложить нехилую метамодель, что-то вроде http://www.cwmforum.org/CwmAOM.pdf или другую.

Возможно, более опытные товарищи меня поправят?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Суббота, 10 Ноябрь, 2012 20:49 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
В общем, сказанное подтверждается в основном и практикой... да и теорией где-то... Современной логикой, например...
Прежде всего - что модульность нужна единообразная не только в программной части. А ссылки должны обеспечивать прежде всего "повторное использование"... Кстати, понимание структуры связей зависит прежде всего не от их количества, а от степени совпадения принципов структурирования связываемого у разных людей... всё тот же тезис Козьмы Пруткова... :) Заслуживает внимания замечание того же Шалака, что язык должен быть адекватен тому, о чём на нём говорят...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Понедельник, 12 Ноябрь, 2012 10:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
И ещё о логико-математической формализации. Не только Седов указывал на особенности приложения математического подхода. У того же Герасименко говорится о "нестрогой математике". Причём изложение её алгоритмов наводит на мысль именно об информатизации таблиц решений...
Далее. Следует разделять логику и математику. Т.к. у них есть и специфические проблемы. У первой - скажем, концептуальные, на котоорые указывал тот же Шалак. Отсюда может оказаться, что проблемы с "кусочностью" матмоделей в основном связаны с "втискиванием" рассуждений в не вполне адекватный базис выражения. У второй - скажем, с изменением корректности решений.
В принципе и таблицы решений уже в том или ином виде применяются. Что можно видеть, например, на Рис.4 в этой статье: http://issuu.com/cta-mag/docs/20104028? ... =%23222222. Имеются в виду списки условных переменных на дугах переходов. Кстати, система переходов, не удовлетворяющая требованиям полноты и/или непротиворечивости - самая та таблица решений по Хамби... :)
Системно их можно применить, например, если использовать как форму записи потока управления процессов, суть которых разработчику пока не ясна. Прежде всего это координационные и поисковые процессы. В то же время здесь важно будет и использовать результаты того же Потопахина - те самые "немногие базовые правила поиска решения".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 14 Ноябрь, 2012 09:27 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Кстати, для начала о eEPC. Эта нотация - по сути, те же операторные схемы. Что нетрудно видеть, допустим, у Лаврова (не уверен, что соответствующие пункты вошли в выдержки). Только тут:
    * узлы форматированы по графике и цвету - что по замыслу неплохо, но требует рассмотрения с позиций эргономики - в частности, соответствия еЕРС-графики величин и ГОСТ 19.701 в части "схем данных" - тогда читать привыкшим к БС будет легче, и не будет лишних вариантов :);
    * схемы реорганизованы на плоскости - здесь видна попытка прийти к блок-схемам, однако Владимир Даниелович, думаю, подверг бы результат серьёзной критике - и я бы с ним тут согласился :).
А вот главное-то сходство с опер-схемами осталось - все составляющие смысла алгопроцесса (в той, части, в какой у разработчиков получилось их выразить) "свалены в кучу".

Отсюда следующее. За обсуждениями схемных нотаций в последнее время было весьма интересно следить (особенно тут и в теме Р-схем, где как-то обходилось без аргументации в стилях кавалера "Большого креста..." и/или доктора пропаганды :wink: :|). Но. Мне всё хотелось увидеть решение такое, что заставило бы принять его взамен (ну или в усовершенствование) применяемого мной. Не увидел... И поскольку уже, видимо, все предложили всё оригинальное (и/или указали на всё знакомое) - представлю своё для обсуждения. На таком примере:
Вложение:
Рисунки A4 ГрафитМод ТехОп - ВетвАлгоПроц (свёртка, дин+стат, скоб).png
Рисунки A4 ГрафитМод ТехОп - ВетвАлгоПроц (свёртка, дин+стат, скоб).png [ 135.11 КБ | Просмотров: 12286 ]
- с обобщением содержания атрибутивного (в смысле генклассификации) для удобства и компактности.
Сначала немного по форме. Синтаксис структурной составляющей, как можно видеть, скобочный. Язык несколько отличается от PureBuilder-предложения - что обусловлено в первую очередь завершённостью определения. Дабы: а) реально собирать из РВ-скобок алгоструктуры и б) вполне свободно переходить от них как к текстовой записи, так и к графовой. Ну и наоборот тоже - как и предлагает Илья Евгеньевич в докладе об инженерии в качестве важнейшего умения ИТ-инженера (собственно, инженера любого - это в ИТ только начинают уходить от строительства мостов на глазок из жердей и веток к... ну хотя бы акведучным конструкциям... :wink: :|).
    Скобки выбраны потому, что описание структуры в такой форме получается проще, чем в графовой. Ведь это, по сути, разновидность таблиц (к этому ещё вернёмся).

Всякие цвета, скобки, индексы что значат - можно смотреть пока в предметном указателе, представленном здесь: viewtopic.php?p=76210#p76210 - на первых страницах.


Теперь по содержанию и как оно выражено. Прежде всего это та самая "трёхполосная вьюшка", обсуждавшаяся здесь: viewtopic.php?p=74873#p74873. Точнее, её средняя - информатическая - часть. Связи с качественной и логико-математической частями (полосами) только намечены - граничными скобками (по правому и левому краям).

Инфор-часть, как видно, состоит из трёх столбцов. Они названы на выносках внизу. Чтобы долго не объяснять - это те самые "три абстракции" из базиса Кауфмана. Как он обсуждался здесь: viewtopic.php?p=71247#p71247.

По импер-столбцу скажу только, что организация маршрутов здесь линейная ("одномерная" в терминах "критиков текста"). Однако ничто не мешает перестроить её в двумерную - причём не менее двумерную и не менее структурную, чем в случае граф-записи (дракон-нотации)... :) Что самое интересное - и текст-то ничто не мешает перестроить так же - о чём говорилось здесь: viewtopic.php?p=73919#p73919. В общем, полный изоморфизм базисов по Ермакову... :)

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

Здесь важно понимать вот что.

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

Во-вторых, на примере совмещены статика и динамика. В общем случае надо анализировать допустимость этого. А тут вопрос к теории деятельности (алгоритмов и их систем). Об этом лучше всего Александр Сергеевич высказался: viewtopic.php?p=66809#p66809.

И в-третьих. Как же нам представить-то связывание для общего случая? А тут надо вспомнить, что за абстракцией связывания стоит исполнитель алгопроцессов. Представленный моделями абстрактных "языковых машин" различных классов (по Тьюрингу/Посту, Черчу, Маркову). Так что один путь - отображать связь состояния такой "машины" на каждом шаге с состояниями на других шагах. Тут нам поможет подход "табличных процессоров" (вот мы и вернулись к "скобкам как таблицам"). Т.е. можно представить себе действия и состояния как ячейки динамической таблицы, которым соответствуют формулы. А связывание показывает зависимости формул.
    Думаю, теперь и возможную реализацию объяснять не надо :) - только отмечу, что актуально будет усовершенствование Дмитрия_ВБ. Имеется в виду "расцветка" схем зависимости, предложенная здесь: viewtopic.php?p=73043#p73043. Кстати, то же самое делаю для текста - разные категории связей обозначены разными цветами закладок/ссылок.
Другой путь очевиден, если вспомнить, что исполнитель-то тоже имеет структуру. Представляемую в графит-терминах актив-схемами - а по сути, схемами систем по ЕСКД. Так что выделяем из такой схемы тракты, имеющие отношение к текущему шагу - и связываем их входы с аргументами состояния (и формул операций) шага, а выходы - с результатами. Т.е. схема трактов будет ядром связывания - ну и помещается в его колонке.

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

А отсюда можно перейти к вопросу - а как описывать операции и состояния нетекстово?
Для операций возможны те же FBD-схемы. Для случая программной реализации - именно так, как Дагаев и предложил - вписывая схему переработки в блок действия. Или деревья выражений - как в ПЕКАНе: viewtopic.php?p=68848#p68848.
Для состояний - очевидно, та же "машина Тьюринга" в текущей конфигурации. Ну там, как опять же в ПЕКАНЕ, таблица текущих значений величин, участвующих на шаге. Или АТ-схема - также в затрагиваемой части - о чём говорил здесь: viewtopic.php?p=72538#p72538. А также для допрограммной формализации уместны схемы ресурсов. Кстати, легко видеть, что это те же опер-схемы - только отдельно для шага. Ну и графика по стандарту блок-схем для данных.
    И вот тут мы снова возвращаемся к статике и динамике. Ибо перечисленные формы вполне адекватны представлению состояний именно статических - "что получилось". Для машины-то это хорошо - расписали величины, типы и значения - и можно контролировать, тестировать/верифицировать... А для исполнителя-человека? Ну-ка, вспомним, как учат солдат? рабочих? врачей? актёров, наконец?.. Верно - через "показ", что получается. Т.е. развёртыванием состояния, стоящего за "именем действия" и его формулировкой (пусть самой точной - но статической по сути), в динамике. Как это? Спасибо Дмитрию Колосову - по его ссылкам нашёлся пример наглядный: http://www.youtube.com/user/AlgoRythmics.
    Ну, куда это подставляется в предложенной структуре модели - думаю, объяснять не надо... :)
Кстати, на этих роликах можно видеть и роль специальной модельной разметки. На них определена, так сказать, "предметная", обозначающая сущности как элементы структуры предметной среды в динамике её "вычислительного состояния". У меня возникала обычно задача обратная - "динамизировать" статическую картину предметной среды. Для чего была определена разметка "диостропами": http://grafit-basis.narod.ru/L3/usl_obo ... ril1-n1223. Собственно, то же делал и В.Д. для описания операций "исчисления слепышей" - только по-своему (вписывая в таблицу)... Изначально делал так же (можно видеть для ввода атома в Драконографике), а диостропы необходимы в целях большей наглядности.

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

Ну и наконец - в построении нотаций следует учитывать сказанное Алексеем: viewtopic.php?p=75373#p75373. Дабы обеспечить "эргономику информационных представлений". С учётом этого из сказанного видятся такие "задачи на перспективу".

1. Ещё раз обдумать и обсудить - какие ещё возможны решения, кроме предложенного? или его усовершенствования?

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

Речь и там, и там, думаю, должна идти прежде всего о структуре и свойствах атрибутов - насчёт форматов не следует забывать замечание Kori отсюда: viewtopic.php?p=74438#p74438 ("когда программисту делать нечего - он цвета настраивает" :) ). Т.е. сильно много настраиваемых вручную представлений не надо - следует выделить ситуации применения и определить для них типы вьюшек. Где в основном всё настроено по умолчанию. При реализации этого важно, считаю, предложение Сергея Прохоренко о вкладках - разным вьюшкам можно отвести свои табы и держать их одновременно, переключаясь для лучшего понимания.


Последний раз редактировалось Владислав Жаринов Четверг, 13 Декабрь, 2012 09:12, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 29 Ноябрь, 2012 08:58 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Теперь, возможно, заслуживают внимания публикации по "миварной технологии". Собственно, нового там немного(относительно таблиц решений и машин теорий), но систематическое изложение позволит позиционировать разрозненные идеи как участников темы, так и цитируемых источников. Позиционировать по отношению к рабочему прототипу.

общая презентация:
Вложение:

сайты по "миварной технологии":
остальное гуглится через


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 29 Ноябрь, 2012 09:20 

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 29 Ноябрь, 2012 09:35 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
AI - слишком дурная трава, чтобы курить её здесь :)

Позиционируется просто:
две колонки Усова - двудольный граф из
Вложение:

Ваши три колонки - трёхдольный граф из
Вложение:

ну и т.д. и т.п.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Четверг, 29 Ноябрь, 2012 10:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Спасибо! Ну, в общем, надо понимать так, что товарищи тоже идут в русле, намеченном Кауфманом более 25 лет назад... :) Хотя в том, что навёрнуто для вывода, надо ещё разбираться... тем, кто по содержательной части... моя же задача - нотации для содержания определить... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Пятница, 30 Ноябрь, 2012 00:06 
Модератор
Аватара пользователя

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


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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Задача на перспективу
СообщениеДобавлено: Вторник, 15 Январь, 2013 12:09 

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


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

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


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

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


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

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