Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 »
271
Другой причины для дублирования кроме одновходовости пока не придумывается.

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

Конечно, если диаграмма рисуется для чтения человеком, то "мертвое" лучше с неё убрать.

Ссылка на Матлаб прекрасна. Там и про history junction замечательно написано. Только переводчик ленивый.) Пример без действий, и локальный переход может быть нелокальным -- смысл не меняется. Есть полный пример с действиями: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant35.html#1028350
Ну и "вкуснятинка" вроде того, что "вертолётной площадки" достаточно, переход в неё может не вести, любой переход к границе суперсостояния на самом деле ведёт к ней (если история не пуста).
И это не choice'ы, это такие junction'ы.) Цикл отработает до выхода из состояния)): http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant40.html
Их можно ставить всюду, даже после начального псевдосостояния. Начальных может быть несколько: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant31.html
А иногда их можно использовать для того, чтобы вернуться назад как ни в чём не бывало: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant45.html

272
Буч как первоисточник кучи ошибок, это здорово. Может быть, всё дело в различиях версий UML?

273
1. Да, по стандарту.

2. Нет. Если State1 и/или State2 -- junction'ы, то прежде следует преобразовывать их. Если State1 и/или State2 -- не junction'ы, и State3 -- choice, то [если мы верим в одновходовые choice] State3 дублируется State3bis и мы получаем:
State1 --[guard1 && guard2]/act1, act3-->State3--> [тут ветки State3]
State2 --[guard2 && guard3]/act2, act3-->State3bis--> [тут ветки State3]

3. Если State2 = State3 и эта вершина choice, то мы получаем:
State1 --[guard1 && guard2]/act1, act3-->State3--> [тут нерефлексивные ветки State3]
к State3 дорисовываем дополнительную ветку, соответствующую одному витку цикла:
State3 --[guard2 && guard3]/act2, act3-->State3bis--> [тут нерефлексивные ветки State3]
к State3bis дорисовываем дополнительную ветку, соответствующую двум виткам цикла:
State3bis --[guard2 && guard3]/act2, act3-->State3bisbis--> [тут нерефлексивные ветки State3]
к State3bisbis дорисовываем ...
т. е. выращиваем бесконечное дерево переходов-звеньев.
Это если придерживаться духа стандартных примеров по использованию junction и choice.
Либо, как предлагалось, превращаем choice в обычное состояние.

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

274
Звено от junction к choice не обладает действиями, поэтому склеивая звенья-половинки (и действия на них) получим те же действия, что и на другой половинке.
Звено от junction к choice не обладает сторожем, что равносильно постоянной ИСТИНЕ, поэтому склеивая звенья-половинки и перемножая сторожей получим того же сторожа, что и на другой половинке.
Дело не в склеивании как таковом. При удалении junction мы вместо одного сложного перехода получаем несколько простых, решенных статически. Тут так не удастся: либо создастся дубль choice со звеном одновременно входящим и выходящим из него (и это будет его единственный вход); либо создастся бесконечное количество "простых" переходов: с одним, с двумя, с тремя, ... с N, ... choice'ами без "рефлексивного звена". Отвечая я мысленно дорисовываю действия к Вашему примеру, т. к. обеднённый частный случай, к. м. к. не показателен.   
А возможны ли недостижимые вершины для well formed? Понимаю, что инструмент (типа EA) их должен поддерживать - как иначе сохранить промежуточный результат работы над диаграммой/моделью, но в конечном результате им нет места!
Разрешено всё, что не запрещено.) Я не знаю. Мне кажется, в попытках определять ill- и well formed создатели стандарта UML пока не преуспели.

275
Как я понимаю - во вложении.
Junction можно рисовать, если статически можем его удалить, склеивая звенья-половинки (и действия на них), а также перемножая сторожей. В нижней картинке junction неудаляемый (таким образом). Эквивалентная конструкция приводилась выше -- вместо сколькиугодновходового choice обычное состояние.
Пойдем по шагам - надо ли гарантировать, что условие хотя бы одного выходящего из choice звена должно быть истинным?
В общем случае, не надо. Ведь бывают недостижимые choice. [И чего они в OCL требуют, чтобы были входящие звенья? Из текстового описания не следует, что они должны быть для well formed. Правда, придётся помучиться, чтобы отличить начальное псевдосостояние от junction без входов.))]

276
Ничего лучшего не придумал, кроме как накапливать и согласовывать факты про choice.
  • ровно одно из выходящих звеньев должно быть с else (наиболее простой способ гарантировать выход из choice)
  • выходящие звенья имеют guard и не имеют trigger
  • имеется хотя бы одно входящее звено
Пункт 1 -- лишь рекомендация стандарта (не согласующаяся с OCL, т. к. тогда бы выходов было >1).

277
В поддержку choice со множественными входными звеньями. Вместо choice со множественными входными звеньями сделаем junction с теми же входными звеньями расположенное в том же состоянии, что и choice, а от junction к choice сделаем звено без события, сторожа и действий - получается вполне допустимая конструкция, которая работает точно так же.
Будет ли замещающая конструкция работать при ориентированном цикле из звеньев, включающем исходный многовходовый choice?

278
Реализаторам choice со множественными входными звеньями точно не понравится. Miro Samek со state-machine.com писал на тамошнем старом форуме, что branch'ующий choice "coded as if (...) else if (...) ... else ...". Очевидно, что стандартный choice приведёт к чему-то другому (по-моему, к проходным состояниям и к коротким переходам-звеньям между ними). 

279
Я не берусь так сразу подобрать убийственный аргумент.) Немного странно, что choice со многими входными звеньями и одним выходным всё ещё будет choice'ом, а не каким-нибудь merge'ом. Как заклинание в тексте branch-branch, а OCL вдруг открывает перспективу соорудить на choice'ах вложенную псевдодиаграмму деятельности, описывающую динамическую "передачу управления" между состояниями. Я полагало, что branch'и как раз для того, чтобы не было ориентированных циклов внутри составных переходов. Тут бы слово/пример от какого-то гуру позволил бы сжиться с таким моим недопониманием.

Не стоит досадовать. Ваше участие очень многое даёт мне. Раскрываете шире мне глаза.

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

Против одного выхода из choice могу указать примеры со http://www.state-machine.com/ где нестандартная, но похожая на стандартную нотация и придумано, что не бывает простых переходов со сторожами. Вместо них рисуется составной через choice с одним выходящим звеном.

см. https://www.state-machine.com/qm/sm_tran.html
По стандарту B -- это почти всегда ill formed диаграмма, не эквивалентная A. Небранчующий choice даёт поводы рисовать такое. Наброс слабый, но как первый подход, прошу зачесть.)
Пример, с другой стороны интересен тем, как реализация влияет на язык.

280
Когда я прилетело со своей родной планеты мне тоже было в новинку, что здесь НЛО, кофе и виски имеют средний род. Но я законопослушное, а хабрахабр и вслед за ним энциклопедический, толковый и орфографический словари не могут ошибаться. ;D

281
Замечу, что допустимы на основе OCL-ограничения, не нашедшего явного подкрепления (как и опровержения) в английском тексте.

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

Слить entry и exit можно, но иногда это повлияет на смысл, ведь сторожа на звеньях, исходящих из состояния (пусть и проходного), проверяются до exit'ов и, естественно, после entry.

Есть она курьёзная картинка Fig. 27 в статье "On visual formalisms" Communications of the ACM, 1988. Правда, к ней дан комментарий как к 28й.

282
Choice может иметь и несколько входов [стандарт 14.5.6.6: "In a complete statemachine, a choice Vertex must have at least one incoming and one outgoing Transition.
inv: (kind = PseudostateKind::choice) implies (incoming->size() >= 1 and outgoing->size() >= 1)
"], в том числе (в отличие от junction) и рефлексивные как раз за счет того, что "С choice'ами условия-части проверяются "динамически"".
Удивительно [для меня]! Совсем недавно видело указание про единственный вход и [мне] казалось, что с опорой на стандарт (старый?). Что это было? Спутало с fork? Благодарю за подмеченный Вами факт. Есть множество примеров, где choice разветвляет, но ни одного, где соединяет и [тем более] циклит рефлексивным звеном. Явно указано, что мёржить звенья надо junction'ом, что можно расценить как рекомендацию. В спецификации стандарта 2.1.1 [как минимум] указано про одно входящее звено. В UML 2 Certification Guide говорится, что choice не мёрджит. В Rational SA у choice 1 вход.

Кстати или нет, рядом висит ограничение про то, что из начального псевдосостояния выходит неболее чем одно звено. Интересно, что имели в виду авторы стандарта под начальным псевдосостоянием без выходящего звена?)

Entry и exit -- это полезный синтсахар, его ещё Харел добыл. Он упрощает диаграмму за счёт сокращения надписей (попутно усложняя её чтение).

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

283
Радо новой встрече.

Написанное справедливо при обратной замене состояний, заместивших собой choice'ы. В общем случае замена на choice возможна не всегда. Choice одновходовый, а "неустойчивое" состояние может иметь столько входящих переходов, сколько нужно (в том числе рефлексивные), а также действия по входу и по выходу, которых choice лишён. Отметим момент: что если бы вместо choice имелась возможность метить состояние как неустойчивое ("зависание" в котором = ill formed)? Было бы выразительнее, не находите? Замещающее choice "неустойчивое" состояние может не только его имитировать, но и описывать более сложное поведение.

С junction'ами все действия по выходу выполняются после проверки сторожевых условий, составленных из условий-частей на звеньях, составляющих композитный переход. А действия по входу -- после выполнения композитных действий по переходу, составленных из действий-частей на звеньях. С choice'ами условия-части проверяются "динамически" (цитирую стандарт), т. е. перед проверкой будут выполнены некоторые действия по выходу и действия-части на ранее пройденных звеньях. Поэтому расположение junction'ов неважно, но важно пересечение звеньями границ состояний. Например, два нижних junction'а можно поместить в St01, а два верхних -- в St0. Смысл диаграммы не изменится, т. к. звенья сохранят свою топологию. Перемещение choice'ов изменит поведение автомата. Также поведение изменится, если звено выгнется и пересечёт дополнительно какую-то границу.

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

284
Продолжим эксперимент. Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому. Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.

285
Вот ещё пара копеек про составные переходы.
Примеры с псевдосостояниями выбора обычно таковы, что эти псеводсостояния находятся на одном уровне с состоянием-исходом и целевыми состояниями. Придумаем [довольно бессмысленный] пример, где будет по-другому. В "матрёшке" композитных состояний расположим псевдосостояния выбора на разных уровнях. Приправим блюдо действиями по входу и выходу. Получится что-то вроде приложенной картинки.
Что мы видим? Что псевдосостояние выбора это "синтаксический сахар". Заменим мысленно все ромбики на разрезающие составной переход на части обычные состояния [переходы из которых будут происходить по событию завершения]. Работать обновлённая машина состояний будет также.
Но "синтаксический сахар" у нас странного свойства. Представим, что в каждом ветвлении у нас "плохой" набор условий: вместо [guard] и [else] -- [guard1] и [guard2], которые могут быть одновременно ложны. Диаграмма с псевдосостояниями выбора становится ill formed, а с аналогичными обычными состояниями вполне себе "well formed". При чём well formed диаграмма будет "зависать" также, как ill formed. Ей почему-то это разрешено.
Что в итоге? Выявлен элемент нотации, обогащающий язык единственным дополнительным смыслом -- лишним запретом.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 »