Некоторая трудность в том, что кроме модели другого описания (достаточно точного) поведения калькулятора нет (скачать прогу, которая якобы реализует, я не смогло). Поэтому логику приходится "считывать" из модели.
Пока прога не изготовлена, модель - это единственное место, в котором может быть достаточно точное описание
Например, мне кажется логичным negated прятать внутрь operand'ов. Ведь знак - это часть записи операнда.
Это если считать, что название состояния (в том числе и композитного) абсолютно точно передаёт его смысл. Чаще встречается ситуация, когда сначала выделяются безымянные состояния (в том числе и композитные), определяются их точные свойства, а наименование подбирается потом, исходя из соображений, что суть надо более-менее отразить, но наименование не должно быть длинным. Например operand1 более точно назвать "операнд 1 без знака", но это длинно.
Наличие отдельного от begin result'а (а вслед за ним и ready) выглядит ненужным усложнением.
Для begin есть возможность задать знак (переход к negated1), а для result - нет, различия есть. Много общего, но есть различия - делай композит.
Я считаю главным недостатком дублирование "подавтомата" для ввода операнда. Представим, что надо добавить в калькулятор числа с плавающей точкой (в тексте автор путает[!!!] их с числами с фиксированной точкой). Апгрейдить придётся обе копии подавтомата. А зачем?
Согласен, что и такой недостаток есть, обсуждать планировал позже (есть подозрение, что он лечится очень непросто).