Диаграмма состояний: choice vs junction(Прочитано 25439 раз)
На диаграмме 1 из State1 по событию b произойдет переход в State2.
На диаграмме 2 из State1 по событию b произойдет переход в State3.
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?



Re: Диаграмма состояний: choice vs junction Ответ #1 : 18 Августа 2016, 15:04:52
Это головоломка? Чем отличаются диаграммы 1 и 2?
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Диаграмма состояний: choice vs junction Ответ #2 : 18 Августа 2016, 19:27:28
Условия переходов из choice проверяются на момент входа в него, переменная А к этому моменту имеет значение 1.
Условия переходов из junction проверяются на момент выхода из настоящего (не псевдо) состояния, переменная А к этому моменту имеет значение 0.
Строго по этим правилам в диаграмме 3 произойдет переход в State3. Но это как-то неестественно (подряд два перехода с одним и тем же условием, но по одному идём, а по другому - нет).




Re: Диаграмма состояний: choice vs junction Ответ #3 : 19 Августа 2016, 08:56:43
Главное – не использовать такие картинки в реальных проектах.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Диаграмма состояний: choice vs junction Ответ #4 : 20 Августа 2016, 12:04:06
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?
Если трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей, то для ответа на вопрос, нужно переписать диаграмму без спец. обозначения. Получаем:
<>--[a=1 and a=1]-->State2
и
<>--[a=1 and a!=1]-->State3
Ответ: State2.
[...и улетело НЛО.]



Re: Диаграмма состояний: choice vs junction Ответ #5 : 21 Августа 2016, 13:02:20
трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей
Класс! Я только чувствовал, что так должно быть, а теперь получил и обоснование.
К сторожам можно добавить триггеры и действия на переходе (более удобной записи переходов: триггеров, сторожей и действий). Триггер не более, чем 1 на всей цепочке переходов через junction, выходящей из состояния (для остальных цепочек триггеров не может быть).
Цепочки переходов через junction не могут быть циклами (через choice могут!).



Re: Диаграмма состояний: choice vs junction Ответ #6 : 22 Августа 2016, 01:23:22
Проблема стандарта в том, что эти вершины-псевдосостояния и звенья-псевдопереходы для авторов стандарта как бы заслонили тот факт, то [настоящая] диаграмма состояний описывает табличку [настоящих] переходов между [настоящими] состояниями.  В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам. Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.
[...и улетело НЛО.]



Re: Диаграмма состояний: choice vs junction Ответ #7 : 22 Августа 2016, 10:33:25
В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам.
По-моему так и надо, если:
  • граф получается наглядным
  • есть хорошие правила, которым граф должен соответствовать (синтаксис)
  • есть хорошие правила получения автомата из графа (семантика)

Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.
Берётся, но не достигает.



Re: Диаграмма состояний: choice vs junction Ответ #8 : 22 Августа 2016, 12:03:46
Берётся, но не достигает.
Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных. Наоборот применяется растушёвка: вершины стабильные и нестабильные; звенья/переходы/составные переходы.
« Последнее редактирование: 22 Августа 2016, 12:12:07 от [прилетело НЛО и...] »
[...и улетело НЛО.]



Re: Диаграмма состояний: choice vs junction Ответ #9 : 22 Августа 2016, 16:24:54
Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных.
Из-за того, что "почти не отличимый в простых случаях" делается попытка делать одно общее описание сразу для обоих слоёв, что приводит к полной неразберихе в сложных случаях.
Хорошая формулировка проблемы - если вместо "граф" и "таблички" подставлять другие термины, то получается описание другой проблемы, когда несколько разных слоёв пытаются представить общим описанием.



Re: Диаграмма состояний: choice vs junction Ответ #10 : 01 Апреля 2017, 10:50:40
Вот ещё пара копеек про составные переходы.
Примеры с псевдосостояниями выбора обычно таковы, что эти псеводсостояния находятся на одном уровне с состоянием-исходом и целевыми состояниями. Придумаем [довольно бессмысленный] пример, где будет по-другому. В "матрёшке" композитных состояний расположим псевдосостояния выбора на разных уровнях. Приправим блюдо действиями по входу и выходу. Получится что-то вроде приложенной картинки.
Что мы видим? Что псевдосостояние выбора это "синтаксический сахар". Заменим мысленно все ромбики на разрезающие составной переход на части обычные состояния [переходы из которых будут происходить по событию завершения]. Работать обновлённая машина состояний будет также.
Но "синтаксический сахар" у нас странного свойства. Представим, что в каждом ветвлении у нас "плохой" набор условий: вместо [guard] и [else] -- [guard1] и [guard2], которые могут быть одновременно ложны. Диаграмма с псевдосостояниями выбора становится ill formed, а с аналогичными обычными состояниями вполне себе "well formed". При чём well formed диаграмма будет "зависать" также, как ill formed. Ей почему-то это разрешено.
Что в итоге? Выявлен элемент нотации, обогащающий язык единственным дополнительным смыслом -- лишним запретом.
[...и улетело НЛО.]



Re: Диаграмма состояний: choice vs junction Ответ #11 : 02 Апреля 2017, 11:05:35
Продолжим эксперимент. Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому. Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.
[...и улетело НЛО.]



Re: Диаграмма состояний: choice vs junction Ответ #12 : 02 Апреля 2017, 11:48:25
Если имеются состояния, все переходы из которых будут происходить по событию завершения, и выполняется условие, что хотя бы один переход сработает ("хороший" набор условий), то такое состояние может/должно быть заменено на choice. Из выгод от этого пока вижу только одну: глянув на диаграмму с choice сразу видно, что "устойчивых" состояний только 5. На диаграмме без choice необходимо вчитываться (всматриваться), чтобы определить, что 4 из 9 состояний - неустойчивые.
Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому.
не понял

Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.
В метамодели Transition имеет обязательное значение container:Region. Оно должно подчинять и вход и выход, и именно по цепочкам до него происходят пересечения границ сначала изнутри-наружу, а  потом снаружи-внутрь.



Re: Диаграмма состояний: choice vs junction Ответ #13 : 02 Апреля 2017, 20:16:04
Радо новой встрече.

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

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

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



Re: Диаграмма состояний: choice vs junction Ответ #14 : 03 Апреля 2017, 12:50:18
Радо новой встрече.
Я тоже!
Choice одновходовый, а "неустойчивое" состояние может иметь столько входящих переходов, сколько нужно (в том числе рефлексивные), а также действия по входу и по выходу, которых choice лишён.
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'ами условия-части проверяются "динамически"".
Что касается действий по входу и выходу:
  • они являются "синтаксическим сахаром"
  • по входу могут быть обозначены с помощью junction - все входящие переходы не в choice, а в junction, и один переход (сегмент) из junction в choice с необходимым действием. Возможно и для действий по выходу можно что-то придумать
С junction'ами все действия по выходу выполняются после проверки сторожевых условий, составленных из условий-частей на звеньях, составляющих композитный переход. А действия по входу -- после выполнения композитных действий по переходу, составленных из действий-частей на звеньях. С choice'ами условия-части проверяются "динамически" (цитирую стандарт), т. е. перед проверкой будут выполнены некоторые действия по выходу и действия-части на ранее пройденных звеньях. Поэтому расположение junction'ов неважно, но важно пересечение звеньями границ состояний. Например, два нижних junction'а можно поместить в St01, а два верхних -- в St0. Смысл диаграммы не изменится, т. к. звенья сохранят свою топологию. Перемещение choice'ов изменит поведение автомата. Также поведение изменится, если звено выгнется и пересечёт дополнительно какую-то границу.
Спасибо, мне стало понятно.
Рекомендованным стандартом контейнером-владельцем является расположенный глубже всех и содержащий вершину(ы)-начало(а) перехода и вершину(ы)-конец(цы). В нашем примере стандартным владельцем будет регион состояния St0. Это не позволяет где-либо кроме как на диаграмме увидеть, что переход пересекает границы St0.
Есть версия, что стандарт ошибается, говоря про "глубже всех", годится любой, содержащий начало и конец. В примере (для [guard2]/act2) это регион, описывающий весь автомат (по стандарту каждый регион относится или к какому-то состоянию, или к автомату вцелом)
« Последнее редактирование: 03 Апреля 2017, 13:57:32 от Vadim »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19