web семенары

[alexus]

К данному моменту на семинаре зарегистрировалось 2 человека.

[Влад Жаринов]

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

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

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

[alexus]

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

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

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

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

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

[Влад Жаринов]

Т.е. язык моделирования (по крайней мере; м.б. и последующих этапов) предметно-специфичны?

[Влад Жаринов]

...

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

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

Да, вот я тоже вспомнил отчасти определения уровней: http://forum.oberoncore.ru/viewtopic.php?p=69450#p69450 ...
В общем, будет некая треугольная матрица в измерениях "уровень развитости системы - уровень структуры системы"... где низшая развитость ("системы с неподвижными частями") - один низший структурный уровень (исполнительный), а высшая развитость ("системы, способные творить") - все четыре уровня... а на промежуточных уровнях развитости число уровней структуры дискретно-монотонно меняется... так?..

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

Кстати, в средства выражения будет входить это:

...
Давайте по порядку. Система обладает состояниями, и поведение системы зависит от того, в каком состоянии она находится. Согласны?.. Но это означает, что одни и те же свойства/методы системы различаются по своим проявлениям в зависимости от того, в каком состоянии находится система. Можно, конечно, внутрь каждого метода вставить инварианты/проверки текущего состояния, чтобы в зависимости от состояния менять реализацию/поведение метода. Но такое решение требует, чтобы во всех методах проверки были согласованы по порядку выполнения, структуре и результату. И если потребуется ввести новую проверку, то её нужно ввести одновременно во все методы чувствительные к данному состоянию. При добавлении нового метода, мы должны аккуратно включить в него все необходимые проверки... для каждого из состояний. И т.д. Большая система характеризуется и большим объёмом свойств (как правило). Поддерживать множество проверок на множестве методов... отдельная нетривиальная и одновременно рутинная задача. Что собственно происходит внутри этих бесчисленных проверок?.. Как правило, проверка на вхождение в определённые диапазоны значений элементов/полей системы. Например, температура здорового человека находится в пределах..., нормативный уровень складского запаса j-той номенклатуры находится в диапазоне... и т.д. и т.п. Собственно, множества (диапазонов) значений множества переменных/элементов системы и образуют состояния системы. Эти состояния проверяются инвариантами. Вполне очевидно, что было бы правильнее определить/задать состояния системы на этапе её проектирования и для каждого состояния написать свой вариант метода, если он чувствителен к данному состоянию. В таком случае система могла бы безошибочно запускать тот вариант метода, который соответствует её текущему состоянию. Можно построить такую простую аналогию. Как известно, объект некоторого класса (в процедурно-объектных языках) обладает своей VMT (virtual method table). В системе таких VMT несколько, по одной на каждое из её состояний (полиморфизм у одного объекта). В таком случае, переход системы из одного состояния в другое связан с простым переключением со "старой" VMT на "новую", которая становится активной для нового состояния. (VMT - как правило, не лучшее, но простое и наглядное решение). Другими словами VMT становится двумерной. По одной стороне по-прежнему идут виртуальные методы, а по другой состояния системы (j-ый метод в i-ом состоянии). При этом никаких проверок состояний, т.е. инвариантов, внутри методов, конечно, делать не нужно. Поэтому я и называю инварианты в ООП "костылями" и суррогатами.
Но введение/оценка/переключение состояний это только небольшая часть проблемы повышения размера/роста/развития систем. Следующий шаг связан с самооценкой, самоидентификацией... оценкой состояния внешней среды, выбор оптимального поведения/самоуправления... И т.д. Это динамический процесс, поэтому надо особенно... тщательно выбирать решения, положенные в основу.

- т.е. язык двумерных таблиц вариантов логики? например, сопоставленных рабочим местам (точнее, видимо, субъектам управления - человек/команда+управляющая языковая машина/комплекс)?

[Влад Жаринов]

Вернулся из отпуска. Ну, думаю, наконец посмотрю семинар, а там 404
wtf?

Наверное время вышло. Бесплатный доступ был до 16 августа, потом, видимо, удаляют тех, кто платно не продлил свою регистрацию.

Будем надеяться, что на новом месте будет удобнее...

[alexus]

Вернулся из отпуска. Ну, думаю, наконец посмотрю семинар, а там 404
wtf?

Наверное время вышло. Бесплатный доступ был до 16 августа, потом, видимо, удаляют тех, кто платно не продлил свою регистрацию.

Будем надеяться, что на новом месте будет удобнее...

Вроде бы получше прошло.
Пишите, если остались вопросы или есть предложения. Обсудим.

[Влад Жаринов]

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

[Влад Жаринов]

Ещё о возможных языках. Вот такой язык для чего-нибудь годится (вот пример его употребления)?..

[valexey]

Ещё о возможных языках. Вот такой язык для чего-нибудь годится (вот пример его употребления)?..

Пример откровенно выглядит как тиичное goto-спагетти.

[Влад Жаринов]

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

[valexey]

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

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

Подобный подход годится только для очень простых систем (либо очень маленьких по размеру, либо имеющих малое число связей/переходов, либо и то и другое вместе).

[Влад Жаринов]

Так декомпозиция же... и разноаспектность.. как в ЕСКД делается (типы схем)... и там же мы не избегаем тех же пересечений связей?..

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

[Влад Жаринов]

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

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

[Peter Almazov]

Вроде бы получше прошло.
Пишите, если остались вопросы или есть предложения. Обсудим.

Может и лучше, но качество связи с моей т.з. неудовлетворительное. Пропущено много мелких кусков, а избыточности русского языка не хватает для восстановления смысла. Мне очень жалко этих пропущенных кусков. Самое главное, что по пропущенному невозможно задать вопрос в принципе. При таком качестве связи считаю вебинары нерациональной тратой времени. Гораздо лучше записать материал в виде лекции, потом  выложить и обсудить. И не будет привязки к конкретному времени, которое многим, видимо, неудобно. Живого общения, конечно не будет, но сейчас оно сводится к вопросу "слышно/не слышно".

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

Вопросы по содержанию вебинара чуть позже.