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