В "A Crash Course in UML State Machines" http://www.state-machine.com/doc/AN_Crash_Course_in_UML_State_Machines.pdf имеется (лист 28) диаграмма, как во вложении.
Вопрос: почему для состояний result и begin заведено композитное состояние ready, а для ready и negated1 - нет?

Вопрос: почему для состояний result и begin заведено композитное состояние ready, а для ready и negated1 - нет?

Интересный вопрос. Варианты ответов:
+ Ready имеет смысл для логики работы калькулятора (в нём он готов к началу нового вычисления);
+ Ready немного упрощает диаграмму и позволяет нормально разместить её на странице;
+ Пример демонстрирует ход создания диаграммы, завершённый достаточно годной версией. Там нет перфекционизма по части достижения максимальной компактности, сокращения количества "повторов" и т. п.

Интересно также наблюдать эволюцию конкретно этой диаграммы в разных версиях текста. Вместо переходных псевдосостояний сейчас псевдосостояния выбора. Появился повод пересмотреть "Practical UML Statecharts in C/C++" II. Где обнаружились паттерны создания диаграмм состояний, пример с "ошибкой Фаулера/Рамбо" и прочие сласти (действие по выходу, управляющее историей состояния).

+ Ready имеет смысл для логики работы калькулятора (в нём он готов к началу нового вычисления);

композит ready и negated1 тоже имеет смысл для логики работы калькулятора - в нём он готов к вводу цифровой части числа-операнда

+ Ready немного упрощает диаграмму и позволяет нормально разместить её на странице;

композит ready и negated1 объединит 3 исходящих перехода (ready объединяет 4). Кстати, отсутствие перехода по OPER от negated1 выглядит подозрительно.

композит ready и negated1 тоже имеет смысл для логики работы калькулятора - в нём он готов к вводу цифровой части числа-операнда

Некоторая трудность в том, что кроме модели другого описания (достаточно точного) поведения калькулятора нет (скачать прогу, которая якобы реализует, я не смогло). Поэтому логику приходится "считывать" из модели. А читатели разные. Например, мне кажется логичным negated прятать внутрь operand'ов. Ведь знак - это часть записи операнда.
Модель, очевидно, не совершена. Наличие отдельного от begin result'а (а вслед за ним и ready) выглядит ненужным усложнением. Вероятно, потому, что т. н. "калькулятор" только "ест" нажатия своих кнопок и куда-то "инсёртит" цифры и что-то "негатит". Но не считает.

композит ready и negated1 объединит 3 исходящих перехода (ready объединяет 4). Кстати, отсутствие перехода по OPER от negated1 выглядит подозрительно.

Всё это так. Но с тем же результатом можно потрошить любой учебный пример.
Я считаю главным недостатком дублирование "подавтомата" для ввода операнда. Представим, что надо добавить в калькулятор числа с плавающей точкой (в тексте автор путает[!!!] их с числами с фиксированной точкой). Апгрейдить придётся обе копии подавтомата. А зачем?

Некоторая трудность в том, что кроме модели другого описания (достаточно точного) поведения калькулятора нет (скачать прогу, которая якобы реализует, я не смогло). Поэтому логику приходится "считывать" из модели.

Пока прога не изготовлена, модель - это единственное место, в котором может быть достаточно точное описание

Например, мне кажется логичным negated прятать внутрь operand'ов. Ведь знак - это часть записи операнда.

Это если считать, что название состояния (в том числе и композитного) абсолютно точно передаёт его смысл. Чаще встречается ситуация, когда сначала выделяются безымянные состояния (в том числе и композитные), определяются их точные свойства, а наименование подбирается потом, исходя из соображений, что суть надо более-менее отразить, но наименование не должно быть длинным. Например operand1 более точно назвать "операнд 1 без знака", но это длинно. 

Наличие отдельного от begin result'а (а вслед за ним и ready) выглядит ненужным усложнением.

Для begin есть возможность задать знак (переход к negated1), а для result - нет, различия есть. Много общего, но есть различия - делай композит.

Я считаю главным недостатком дублирование "подавтомата" для ввода операнда. Представим, что надо добавить в калькулятор числа с плавающей точкой (в тексте автор путает[!!!] их с числами с фиксированной точкой). Апгрейдить придётся обе копии подавтомата. А зачем?

Согласен, что и такой недостаток есть, обсуждать планировал позже (есть подозрение, что он лечится очень непросто).

Пока прога не изготовлена, модель - это единственное место, в котором может быть достаточно точное описание

Автор утверждает в тексте, что есть девайс как "исходник" модели. Который демонстрирует моделируемое поведение. Имелось в виду, что он есть только у автора. В тексте есть одна трасса. И общие слова. По этому мне сложно чекать модель. Судя по фотке девайса, на нем есть кнопки, которых в модели нет.)
 

Это если считать, что название состояния (в том числе и композитного) абсолютно точно передаёт его смысл. Чаще встречается ситуация, когда сначала выделяются безымянные состояния (в том числе и композитные), определяются их точные свойства, а наименование подбирается потом, исходя из соображений, что суть надо более-менее отразить, но наименование не должно быть длинным. Например operand1 более точно назвать "операнд 1 без знака", но это длинно.

По изложению учебного примера выходит не совсем так. С самого начала появляются эти имена (operand1-2), к тому же совпадающие с нетерминалами БНФ.

Для begin есть возможность задать знак (переход к negated1), а для result - нет, различия есть. Много общего, но есть различия - делай композит.

Ну, можно сторожа усложнить и таки "склеить" begin-о-result т. е. ready.
Кажется, автор свои приёмы моделирования рассказывает в PSCC2. Здесь он рассказывает, как может протекать ход моделирования. Неудачно, на мой взгляд.

Согласен, что и такой недостаток есть, обсуждать планировал позже (есть подозрение, что он лечится очень непросто).

Для калькулятора, больше похожего на настоящий, а не на калькулятор Самека, может быть меньше сложностей. Мне так кажется.

Краткие итоги:

• По теме "Когда следует создавать композитное состояние?" - решает автор диаграммы, никаких формальных критериев
• По калькулятору Самека есть вопросы:
  • первый операнд может быть полностью пустым (имеется переход OPER от ready к opEntered), а второй должен включать хотя бы один знак? По БНФ оба могут быть пустыми. По смыслу тоже, если для пустого определено конкретное число, скорее всего 0.
  • полученный промежуточный результат (состояние result) можно заменить набираемым числом (от result тоже есть переходы DIGIT, POINT). Но нельзя сделать это число отрицательным (переход OPER[-] только от begin). Чтобы получить отрицательное число надо сначала набрать DIGIT или POINT, попав в operand1, потом набрать CE, попав в begin, и теперь уж нужное число!
  • если первый операнд отрицательный, то надо набрать DIGIT или POINT (из negated1 нет перехода OPER, завершающего первый операнд), хотя по БНФ это не так
  • какой смысл имеет указание внутреннего перехода без действий, например в zero1 есть внутренний переход без действий по DIGIT_0 и нет перехода по EQUALS - в обоих случаях ничего не происходит.

2. По калькулятору Самека есть вопросы:
...
4. какой смысл имеет указание внутреннего перехода без действий, например в zero1 есть внутренний переход без действий по DIGIT_0 и нет перехода по EQUALS - в обоих случаях ничего не происходит.

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

На "обложке" дана диаграмма калькулятора в нотации Самека, к слову.

P. S. Оценило, что калькулятор иллюстрирует стандартное правило выбора одного перехода из конфликтующих.

На "обложке" дана диаграмма калькулятора в нотации Самека, к слову.

На этой "обложечной" диаграмме свои вопросы:

• почему из zero1 переходы по POINT и DIGIT_1-9 нарисованы по-разному?
• если в состоянии begin будет OPER, но не "-", что дальше подключается OPER из ready или нет?
• что происходит при OPER в negated1: проверку делаем, но в любом случае больше ничего?

P. S. Оценило, что калькулятор иллюстрирует стандартное правило выбора одного перехода из конфликтующих.

Где? Когда из begin есть свой OPER, а из ready свой?

На этой "обложечной" диаграмме свои вопросы:
1. почему из zero1 переходы по POINT и DIGIT_1-9 нарисованы по-разному?

Прети-принтинг) Может быть, так "красивше".)

2. если в состоянии begin будет OPER, но не "-", что дальше подключается OPER из ready или нет?

В PSCC2 есть кусок кода  [p.191] и пояснение к нему. Самек считает, что else ветка в его нотации означает, что событие не обрабатывается, а передаётся дальше обработчику суперсостояния. По стандарту такого быть не может. Одно событие может "поджечь" несколько переходов только, если каждый из них начинается в своём ортогональном  регионе композитного состояния.

 
3. что происходит при OPER в negated1: проверку делаем, но в любом случае больше ничего?

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

 
Где? Когда из begin есть свой OPER, а из ready свой?

Да. Уж было думало, что поймало Самека на горячем, ан нет. Стандарт говорит, что тут всё детерминировано.

Прети-принтинг) Может быть, так "красивше".)

"Обложечная" нотация выглядит более строгой, значит для "красивше" в ней нет места.

В PSCC2 есть кусок кода  [p.191] и пояснение к нему.

Это пояснение:

Note that only the TRUE branch of the if contains the “return Q_TRAN()” statement,
meaning that only the TRUE branch reports that the event has been handled. If the
TRUE branch is not taken, the break statement causes a jump to the final return that
informs the QEP that the event has not been handled. This is in compliance with the
UML semantics, which require treating an event as unhandled in case the guard
evaluates to FALSE. In that case, the event should be propagated up to the higher levels
of hierarchy (to the superstate).

?

Вам не встречалось описание именно "обложечной" нотации? Нашёл! http://www.state-machine.com/qm/sm_choice.html

Самек считает, что else ветка в его нотации означает, что событие не обрабатывается, а передаётся дальше обработчику суперсостояния.

Может наоборот -

There is a difference between a choice pseudostate with an empty else segment and an otherwise identical choice pseudostate without the else segment. The explicit empty else will cause the event to be consumed (without doing anything), while the absence of the else segment will cause the event to propagate to the superstate(s).

http://www.state-machine.com/qm/sm_smstate.html
Воплощены

Я считаю главным недостатком дублирование "подавтомата" для ввода операнда. Представим, что надо добавить в калькулятор числа с плавающей точкой (в тексте автор путает[!!!] их с числами с фиксированной точкой). Апгрейдить придётся обе копии подавтомата. А зачем?

Например, мне кажется логичным negated прятать внутрь operand'ов. Ведь знак - это часть записи операнда.

Это пояснение:?

Оно.

Может наоборот

Может.)
В PSCC2 нет нотации Самека. Так что, это вольное инопланетное допущение, что код имеет отношение к картинке с обложки другой публикации. Поэтому он может расходиться с ним.
QM 4.2.0 вышла в 2018м. Вероятно, к этому времени Самек пришёл к логичному выводу, что раз уж это его прихоть всегда вместе со сторожем рисовать ромб, работать такой однохвостый псевдовыбор должен как обычный UML-переход со сторожем (а многохвостый -- как композитный UML-переход с choice). Раньше он мог думать и рисовать иначе.

Воплощены

Опытный лектор приберегает материал про запас.)