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й.

Совсем недавно видело указание про единственный вход

Уважаемый НЛО, простите, что встреваю в вашу дискуссию, но разве неопознанный летающий объект - это нечто среднего рода?

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

Замечу, что допустимы на основе 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_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) их должен поддерживать - как иначе сохранить промежуточный результат работы над диаграммой/моделью, но в конечном результате им нет места!