Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Vadim от 17 Августа 2016, 20:26:01
-
На диаграмме 1 из State1 по событию b произойдет переход в State2.
На диаграмме 2 из State1 по событию b произойдет переход в State3.
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?
-
Это головоломка? Чем отличаются диаграммы 1 и 2?
-
Условия переходов из choice проверяются на момент входа в него, переменная А к этому моменту имеет значение 1.
Условия переходов из junction проверяются на момент выхода из настоящего (не псевдо) состояния, переменная А к этому моменту имеет значение 0.
Строго по этим правилам в диаграмме 3 произойдет переход в State3. Но это как-то неестественно (подряд два перехода с одним и тем же условием, но по одному идём, а по другому - нет).
-
Главное – не использовать такие картинки в реальных проектах.
-
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?
Если трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей, то для ответа на вопрос, нужно переписать диаграмму без спец. обозначения. Получаем:
<>--[a=1 and a=1]-->State2
и
<>--[a=1 and a!=1]-->State3
Ответ: State2.
-
трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей
Класс! Я только чувствовал, что так должно быть, а теперь получил и обоснование.
К сторожам можно добавить триггеры и действия на переходе (более удобной записи переходов: триггеров, сторожей и действий). Триггер не более, чем 1 на всей цепочке переходов через junction, выходящей из состояния (для остальных цепочек триггеров не может быть).
Цепочки переходов через junction не могут быть циклами (через choice могут!).
-
Проблема стандарта в том, что эти вершины-псевдосостояния и звенья-псевдопереходы для авторов стандарта как бы заслонили тот факт, то [настоящая] диаграмма состояний описывает табличку [настоящих] переходов между [настоящими] состояниями. В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам. Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.
-
В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам.
По-моему так и надо, если:- граф получается наглядным
- есть хорошие правила, которым граф должен соответствовать (синтаксис)
- есть хорошие правила получения автомата из графа (семантика)
Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.
Берётся, но не достигает.
-
Берётся, но не достигает.
Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных. Наоборот применяется растушёвка: вершины стабильные и нестабильные; звенья/переходы/составные переходы.
-
Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных.
Из-за того, что "почти не отличимый в простых случаях" делается попытка делать одно общее описание сразу для обоих слоёв, что приводит к полной неразберихе в сложных случаях.
Хорошая формулировка проблемы - если вместо "граф" и "таблички" подставлять другие термины, то получается описание другой проблемы, когда несколько разных слоёв пытаются представить общим описанием.
-
Вот ещё пара копеек про составные переходы.
Примеры с псевдосостояниями выбора обычно таковы, что эти псеводсостояния находятся на одном уровне с состоянием-исходом и целевыми состояниями. Придумаем [довольно бессмысленный] пример, где будет по-другому. В "матрёшке" композитных состояний расположим псевдосостояния выбора на разных уровнях. Приправим блюдо действиями по входу и выходу. Получится что-то вроде приложенной картинки.
Что мы видим? Что псевдосостояние выбора это "синтаксический сахар". Заменим мысленно все ромбики на разрезающие составной переход на части обычные состояния [переходы из которых будут происходить по событию завершения]. Работать обновлённая машина состояний будет также.
Но "синтаксический сахар" у нас странного свойства. Представим, что в каждом ветвлении у нас "плохой" набор условий: вместо [guard] и [else] -- [guard1] и [guard2], которые могут быть одновременно ложны. Диаграмма с псевдосостояниями выбора становится ill formed, а с аналогичными обычными состояниями вполне себе "well formed". При чём well formed диаграмма будет "зависать" также, как ill formed. Ей почему-то это разрешено.
Что в итоге? Выявлен элемент нотации, обогащающий язык единственным дополнительным смыслом -- лишним запретом.
-
Продолжим эксперимент. Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому. Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.
-
Если имеются состояния, все переходы из которых будут происходить по событию завершения, и выполняется условие, что хотя бы один переход сработает ("хороший" набор условий), то такое состояние может/должно быть заменено на choice. Из выгод от этого пока вижу только одну: глянув на диаграмму с choice сразу видно, что "устойчивых" состояний только 5. На диаграмме без choice необходимо вчитываться (всматриваться), чтобы определить, что 4 из 9 состояний - неустойчивые.
Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому.
не понял
Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.
В метамодели Transition имеет обязательное значение container:Region. Оно должно подчинять и вход и выход, и именно по цепочкам до него происходят пересечения границ сначала изнутри-наружу, а потом снаружи-внутрь.
-
Радо новой встрече.
Написанное справедливо при обратной замене состояний, заместивших собой choice'ы. В общем случае замена на choice возможна не всегда. Choice одновходовый, а "неустойчивое" состояние может иметь столько входящих переходов, сколько нужно (в том числе рефлексивные), а также действия по входу и по выходу, которых choice лишён. Отметим момент: что если бы вместо choice имелась возможность метить состояние как неустойчивое ("зависание" в котором = ill formed)? Было бы выразительнее, не находите? Замещающее choice "неустойчивое" состояние может не только его имитировать, но и описывать более сложное поведение.
С junction'ами все действия по выходу выполняются после проверки сторожевых условий, составленных из условий-частей на звеньях, составляющих композитный переход. А действия по входу -- после выполнения композитных действий по переходу, составленных из действий-частей на звеньях. С choice'ами условия-части проверяются "динамически" (цитирую стандарт), т. е. перед проверкой будут выполнены некоторые действия по выходу и действия-части на ранее пройденных звеньях. Поэтому расположение junction'ов неважно, но важно пересечение звеньями границ состояний. Например, два нижних junction'а можно поместить в St01, а два верхних -- в St0. Смысл диаграммы не изменится, т. к. звенья сохранят свою топологию. Перемещение choice'ов изменит поведение автомата. Также поведение изменится, если звено выгнется и пересечёт дополнительно какую-то границу.
Про регион-владелец стандарт пишет странное (мы уже обсуждали). Можно заметить, что на диаграмме абстрактного синтаксиса из метамодели UML у перехода нет владельца, но есть... контейнер. Далее контейнер и владелец объявляются синонимами.) Рекомендованным стандартом контейнером-владельцем является расположенный глубже всех и содержащий вершину(ы)-начало(а) перехода и вершину(ы)-конец(цы). В нашем примере стандартным владельцем будет регион состояния St0. Это не позволяет где-либо кроме как на диаграмме увидеть, что переход пересекает границы St0.
-
Радо новой встрече.
Я тоже!
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) это регион, описывающий весь автомат (по стандарту каждый регион относится или к какому-то состоянию, или к автомату вцелом)
-
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 -- это полезный синтсахар, его ещё Харел добыл. Он упрощает диаграмму за счёт сокращения надписей (попутно усложняя её чтение).
У Харела были примеры звеньев, прихотливо пересекавших границы состояний. В примерах, подобных таким, контейнера-владельца недостаточно, нужен набор регионов, имеющих отношение к переходу (вероятно, упорядоченный и допускающий повторы).
-
и [тем более] циклит рефлексивным звеном.
Мне примеры с циклами тоже неизвестны. Просто для junction циклы (рефлексивное звено - частный случай цикла) недопустимы: поскольку условия проверяются "не динамически", то если первый раз из junction "пошли" каким-то путём, то и все последующие разы пойдём так же, то есть будем ходить по-кругу. С choice на следующем круге возможны изменения, поэтому циклы (и рефлексивные звенья в том числе) допустимы.
Кстати или нет, рядом висит ограничение про то, что из начального псевдосостояния выходит неболее чем одно звено. Интересно, что имели в виду авторы стандарта под начальным псевдосостоянием без выходящего звена?)
Вполне возможно, что для псевдосостояния (любого типа или нескольких типов) в стандарте есть (или подразумевается) ограничение на наличие хотя бы одного выходного звена.
Entry и exit -- это полезный синтсахар, его ещё Харел добыл. Он упрощает диаграмму за счёт сокращения надписей (попутно усложняя её чтение).
Если состояние "проходное", то entry и exit сливаются в одно действие, и могут быть записаны как только entry (с пустым exit) или как только exit (с пустым entry) - ценность снижается.
У Харела были примеры звеньев, прихотливо пересекавших границы состояний. В примерах, подобных таким, контейнера-владельца недостаточно, нужен набор регионов, имеющих отношение к переходу (вероятно, упорядоченный и допускающий повторы).
Можно более точную ссылку?
-
Замечу, что допустимы на основе OCL-ограничения, не нашедшего явного подкрепления (как и опровержения) в английском тексте.
Странное ограничение для начального псевдосостояния в тексте подтверждается, там также указано: "не более одного выходящего звена" (в стандарте 2.4.1 в тексте было "единственное выходящее звено", а OCL-такой же). Весь большой OCL-фрагмент про входные/выходные звенья псевдосостояний взят из 2.4.1 без изменений.
Слить entry и exit можно, но иногда это повлияет на смысл, ведь сторожа на звеньях, исходящих из состояния (пусть и проходного), проверяются до exit'ов и, естественно, после entry.
Есть она курьёзная картинка Fig. 27 в статье "On visual formalisms" Communications of the ACM, 1988. Правда, к ней дан комментарий как к 28й.
-
Совсем недавно видело указание про единственный вход
Уважаемый НЛО, простите, что встреваю в вашу дискуссию, но разве неопознанный летающий объект - это нечто среднего рода?
-
Когда я прилетело со своей родной планеты мне тоже было в новинку, что здесь НЛО, кофе и виски имеют средний род. Но я законопослушное, а хабрахабр и вслед за ним энциклопедический, толковый и орфографический словари не могут ошибаться. ;D
-
Замечу, что допустимы на основе OCL-ограничения, не нашедшего явного подкрепления (как и опровержения) в английском тексте.
Если бы нашёлся пример того, что наличие нескольких входов в choice вызывает какие-то сложности - это могло бы быть решающим аргументом.
Странное ограничение для начального псевдосостояния в тексте подтверждается, там также указано: "не более одного выходящего звена" (в стандарте 2.4.1 в тексте было "единственное выходящее звено", а OCL-такой же). Весь большой OCL-фрагмент про входные/выходные звенья псевдосостояний взят из 2.4.1 без изменений.
Разработчики стандарта (не конкретно UML, а некоторых других) обнаглели до того, что встречаются ситуации, когда для исключения, например ограничения, диаграмма с ограничением помещается в документ, а в тексте делается запись, что ограничение недействительно. Надо просто перерисовать диаграмму, а лень!
Слить entry и exit можно, но иногда это повлияет на смысл, ведь сторожа на звеньях, исходящих из состояния (пусть и проходного), проверяются до exit'ов и, естественно, после entry.
Опять я облажался - ситуация не сложная, можно было и самому предположить.
Есть она курьёзная картинка Fig. 27 в статье "On visual formalisms" Communications of the ACM, 1988. Правда, к ней дан комментарий как к 28й.
Как я понял, картинка демонстрирует 2 вещи:- вход (выход) по композитному состоянию без выполнения entry (exit)
- многократное пересечение границы, некоторые entry (exit) выполнятся более 1 раза
Обе мне не нравятся (хотя Харел это Харел).
-
Я не берусь так сразу подобрать убийственный аргумент.) Немного странно, что choice со многими входными звеньями и одним выходным всё ещё будет choice'ом, а не каким-нибудь merge'ом. Как заклинание в тексте branch-branch, а OCL вдруг открывает перспективу соорудить на choice'ах вложенную псевдодиаграмму деятельности, описывающую динамическую "передачу управления" между состояниями. Я полагало, что branch'и как раз для того, чтобы не было ориентированных циклов внутри составных переходов. Тут бы слово/пример от какого-то гуру позволил бы сжиться с таким моим недопониманием.
Не стоит досадовать. Ваше участие очень многое даёт мне. Раскрываете шире мне глаза.
В другим местах были картинки-скриншоты из прог от конторы Харела, где переходы рисовались красивыми сплайнами, но из-за этого налезали на посторонние состояния и могло казаться, что при переходе происходят попутные входы и выходы. Тут уже в пору говорить о планарных и непланарных диаграммах состояний. Не знаю, есть ли контрпример, демонстрирующий, что не всегда по правильно определённому владельцу перехода можно понять, к каким ещё другим регионам он относится. Вот бы построить такой.)
Против одного выхода из choice могу указать примеры со http://www.state-machine.com/ где нестандартная, но похожая на стандартную нотация и придумано, что не бывает простых переходов со сторожами. Вместо них рисуется составной через choice с одним выходящим звеном.
(https://www.state-machine.com/qm/sm_guard.png)
см. https://www.state-machine.com/qm/sm_tran.html
По стандарту B -- это почти всегда ill formed диаграмма, не эквивалентная A. Небранчующий choice даёт поводы рисовать такое. Наброс слабый, но как первый подход, прошу зачесть.)
Пример, с другой стороны интересен тем, как реализация влияет на язык.
-
Реализаторам choice со множественными входными звеньями точно не понравится. Miro Samek со state-machine.com писал на тамошнем старом форуме, что branch'ующий choice "coded as if (...) else if (...) ... else ...". Очевидно, что стандартный choice приведёт к чему-то другому (по-моему, к проходным состояниям и к коротким переходам-звеньям между ними).
-
Ничего лучшего не придумал, кроме как накапливать и согласовывать факты про choice.
- ровно одно из выходящих звеньев должно быть с else (наиболее простой способ гарантировать выход из choice)
- выходящие звенья имеют guard и не имеют trigger
- имеется хотя бы одно входящее звено
-
В поддержку choice со множественными входными звеньями. Вместо choice со множественными входными звеньями сделаем junction с теми же входными звеньями расположенное в том же состоянии, что и choice, а от junction к choice сделаем звено без события, сторожа и действий - получается вполне допустимая конструкция, которая работает точно так же.
-
В поддержку choice со множественными входными звеньями. Вместо choice со множественными входными звеньями сделаем junction с теми же входными звеньями расположенное в том же состоянии, что и choice, а от junction к choice сделаем звено без события, сторожа и действий - получается вполне допустимая конструкция, которая работает точно так же.
Будет ли замещающая конструкция работать при ориентированном цикле из звеньев, включающем исходный многовходовый choice?
-
Ничего лучшего не придумал, кроме как накапливать и согласовывать факты про choice.
- ровно одно из выходящих звеньев должно быть с else (наиболее простой способ гарантировать выход из choice)
- выходящие звенья имеют guard и не имеют trigger
- имеется хотя бы одно входящее звено
Пункт 1 -- лишь рекомендация стандарта (не согласующаяся с OCL, т. к. тогда бы выходов было >1).
-
Будет ли замещающая конструкция работать при ориентированном цикле из звеньев, включающем исходный многовходовый choice?
Как я понимаю - во вложении.
Пункт 1 -- лишь рекомендация стандарта (не согласующаяся с OCL, т. к. тогда бы выходов было >1).
Пойдем по шагам - надо ли гарантировать, что условие хотя бы одного выходящего из choice звена должно быть истинным?
-
Как я понимаю - во вложении.
Junction можно рисовать, если статически можем его удалить, склеивая звенья-половинки (и действия на них), а также перемножая сторожей. В нижней картинке junction неудаляемый (таким образом). Эквивалентная конструкция приводилась выше -- вместо сколькиугодновходового choice обычное состояние.
Пойдем по шагам - надо ли гарантировать, что условие хотя бы одного выходящего из choice звена должно быть истинным?
В общем случае, не надо. Ведь бывают недостижимые choice. [И чего они в OCL требуют, чтобы были входящие звенья? Из текстового описания не следует, что они должны быть для well formed. Правда, придётся помучиться, чтобы отличить начальное псевдосостояние от junction без входов.))]
-
Junction можно рисовать, если статически можем его удалить, склеивая звенья-половинки (и действия на них), а также перемножая сторожей. В нижней картинке junction неудаляемый (таким образом).
Звено от junction к choice не обладает действиями, поэтому склеивая звенья-половинки (и действия на них) получим те же действия, что и на другой половинке.
Звено от junction к choice не обладает сторожем, что равносильно постоянной ИСТИНЕ, поэтому склеивая звенья-половинки и перемножая сторожей получим того же сторожа, что и на другой половинке.
В общем случае, не надо. Ведь бывают недостижимые choice. [И чего они в OCL требуют, чтобы были входящие звенья? Из текстового описания не следует, что они должны быть для well formed. Правда, придётся помучиться, чтобы отличить начальное псевдосостояние от junction без входов.))]
А возможны ли недостижимые вершины для well formed? Понимаю, что инструмент (типа EA) их должен поддерживать - как иначе сохранить промежуточный результат работы над диаграммой/моделью, но в конечном результате им нет места!
-
Звено от junction к choice не обладает действиями, поэтому склеивая звенья-половинки (и действия на них) получим те же действия, что и на другой половинке.
Звено от junction к choice не обладает сторожем, что равносильно постоянной ИСТИНЕ, поэтому склеивая звенья-половинки и перемножая сторожей получим того же сторожа, что и на другой половинке.
Дело не в склеивании как таковом. При удалении junction мы вместо одного сложного перехода получаем несколько простых, решенных статически. Тут так не удастся: либо создастся дубль choice со звеном одновременно входящим и выходящим из него (и это будет его единственный вход); либо создастся бесконечное количество "простых" переходов: с одним, с двумя, с тремя, ... с N, ... choice'ами без "рефлексивного звена". Отвечая я мысленно дорисовываю действия к Вашему примеру, т. к. обеднённый частный случай, к. м. к. не показателен.
А возможны ли недостижимые вершины для well formed? Понимаю, что инструмент (типа EA) их должен поддерживать - как иначе сохранить промежуточный результат работы над диаграммой/моделью, но в конечном результате им нет места!
Разрешено всё, что не запрещено.) Я не знаю. Мне кажется, в попытках определять ill- и well formed создатели стандарта UML пока не преуспели.
-
Дело не в склеивании как таковом. При удалении junction мы вместо одного сложного перехода получаем несколько простых, решенных статически. Тут так не удастся: либо создастся дубль choice со звеном одновременно входящим и выходящим из него (и это будет его единственный вход); либо создастся бесконечное количество "простых" переходов: с одним, с двумя, с тремя, ... с N, ... choice'ами без "рефлексивного звена". Отвечая я мысленно дорисовываю действия к Вашему примеру, т. к. обеднённый частный случай, к. м. к. не показателен.
Попробуем разбираться по шагам.- Во вложении эквивалентные конструкции?
- Эквивалентность сохраняется, если вместо state1, state2, state3 использовать псевдосостояния choice и junction?
- Эквивалентность сохраняется, если какие-то из state1, state2, state3 представляют собой одну и ту же вершину?
Разрешено всё, что не запрещено.) Я не знаю. Мне кажется, в попытках определять ill- и well formed создатели стандарта UML пока не преуспели.
Может пришло время явно обозначить, что речь идет не столько о том, что есть в стандарте, как о том, что там должно быть.
Можно применить аналогию: Заказчик составил материал, в котором, по его мнению, есть всё необходимое для Разработчика, но на самом деле предстоит с помощью Аналитика получить новый материал, где действительно будет всё необходимое для Разработчика.
-
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, допустимы.
-
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 дорисовываем ...
т. е. выращиваем бесконечное дерево переходов-звеньев.
Одновходовость choice - это единственная причина необходимости State3bis и т.п. или есть ещё и другие?
Диаграмма состояний описывает работу некоторого исполнителя. В этом можно увидеть повод для аналогий со стандартами языков программирования. Там устанавливаются правила, делающие бессмысленными (ошибочными) некоторые конструкции. Но в программах, составленных по этим правилам могут быть другие бессмысленные места: мертвый и/или недостижимый код. С такой точки зрения, недостижимые фрагменты диаграммы состояний, записанные по стандарту UML, допустимы.
А можно считать ошибкой недостижимость фрагментов диаграммы состояний, хотя бы из соображений минимизации диаграммы. Некоторые так и предлагают http://www.softcraft.ru/auto/switch/umlswecl/umlswecl.pdf стр.7-9
-
К многовходовости и циклам choice: http://matlab.exponenta.ru/stateflow/book1/3.php (правда это не UML).
-
Другой причины для дублирования кроме одновходовости пока не придумывается.
Вообще говоря, то, что у них запрещается недостижимое -- это то ли жлобство, то ли педагогическая заморочка. Даже если сгенерить код по недостижимому, то всё будет работать точно также. "Мертвечину", если что, подберёт компилятор языка программирования. Тут какая-то "изюминка" -- вроде, наша среда может обучать составлению "правильных" диаграмм состояний.
Конечно, если диаграмма рисуется для чтения человеком, то "мертвое" лучше с неё убрать.
Ссылка на Матлаб прекрасна. Там и про 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
-
И это не choice'ы, это такие junction'ы.
Для меня если условие на исходящем звене проверяется не заранее, а по достижении, то это по сути - choice.
-
Для меня если условие на исходящем звене проверяется не заранее, а по достижении, то это по сути - choice.
Я так поняло, что если бы были действия (transition action) на циклическом звене, то цикла бы было как бы два. Сначала перед выходом из состояния ходили бы и считали в уме круги, а уж потом бы вышли и сколько насчитали, столько бы раз запустили transition action. Жуткий гибрид.)