Сначала о глобальном - мне нравится, как проходит обсуждение, поэтому появились вопросы:

• есть ли в интернете другие места (лучше русскоязычные), где обсуждения похожих тем (нюансы языков моделирования) происходят так же конструктивно?
• почему молчит остальная аудитория форума, варианты:
  
  • джуниоры пытаются разобраться в том, что все уже давно знают - пусть разбираются сами, лучше усвоят;
  • очень важная, но сложная тема - сказать по ходу нечего, дождёмся результатов;
  • то, что обсуждают, никому никогда не понадобится, но влезать - себе дороже?

От предыстории по умолчанию можно избавиться, заведя переменную-признак "были ли мы в State1", добавить действия по её инициализации и изменению, раздвоить переходы в State1 через choice/junction со сторожем, который при истинности признака ведёт нас в единое псевдосостояние истории, при ложности -- в нужное подсостояние внутри State1. Понятное дело, что с помощью введения переменной можно вообще избавиться от исторических псевдосостояний.

Наличие и трактовка перехода из исторического псевдосостояния как раз направлены на избавление от такой переменной-признака. Избавление от переменных оправдано тем, что переменные сильно снижают наглядность диаграммы: места, где они изменяются и проверяются ничем визуально не связаны, кроме имени переменной.

Должен сработать компромисс -- усложняя нотацию, соизмеряем, оправдывает ли более трудночитаемое описание языка выгоды от более лаконичных диаграмм в особых случаях.

Несколько псевдосостояний истории в регионе - изменение только в одном месте синтаксиса (0-1 на 0-*), но не семантики (неважно сколько исторических псевдосостояний, при выполнении можем одновременно добраться только до одного).

Как я писал выше, смыслы финального состояния в стандарте не прояснены должным образом. Возможно, что допущение явных переходов из финальных состояний (а также do-деятельностей в них, внутренних переходов) не усложнит язык, а лишь очистит его от лишних запретов. Некоторое затруднение может быть связано с устоявшимся стереотипом, что явных переходов из финального состояния не бывает.

Финальное является именно состоянием, а не псевдосостоянием потому, что автомат может находиться именно в нём (особенно, если это финальное состояние композитного состояния). Отсутствие в финальном состоянии do-деятельностей и внутренних переходов обусловлено тем, что хочется подчеркнуть, что ничего существенного (с точки зрения региона/состояния, к которому относится финальное состояние) уже произойти не может - только выход, причём это будет и выход из региона/состояния. Но оказалось, что в случае композитного ортогонального (в отличие от неортогонального) состояния появляется новая ситуация - часть регионов достигла финального состояния, а часть - нет.

Сначала о глобальном - мне нравится, как проходит обсуждение, поэтому появились вопросы:

• есть ли в интернете другие места (лучше русскоязычные), где обсуждения похожих тем (нюансы языков моделирования) происходят так же конструктивно?
• почему молчит остальная аудитория форума, варианты:
  
  • джуниоры пытаются разобраться в том, что все уже давно знают - пусть разбираются сами, лучше усвоят;
  • очень важная, но сложная тема - сказать по ходу нечего, дождёмся результатов;
  • то, что обсуждают, никому никогда не понадобится, но влезать - себе дороже?

Мне тоже понравился наш обмен мнениями. Так перемыть косточки UML у меня даже с коллегами на работе не получалось.
Других мест не знаю, т. к. не искал. Может быть, кто-то из старожилов подскажет.
Комментировать участие/неучастие в этой теме других участников не возьмусь. Я почти их не знаю.

Наличие и трактовка перехода из исторического псевдосостояния как раз направлены на избавление от такой переменной-признака.

Справедливо. С переменными диаграмма становится более императивной, что не всегда желательно.

неважно сколько исторических псевдосостояний, при выполнении можем одновременно добраться только до одного.

Это так, но, вероятно, придётся прописать такое положение в языке. Сделать это формально (на OCL) затруднительно. Сама нотация может обескураживать: несколько псевдосостояний предыстории  изображают одну предысторию и несколько меток для состояний, являющихся предысторией по умолчанию. Мне кажется, что такая пометка состояния могла бы делаться не звеном из "вертолётной площадки", а тегом на самом состоянии. Хотя такой вариант, скорее всего менее нагляден, чем стандартный.

Отсутствие в финальном состоянии do-деятельностей и внутренних переходов обусловлено тем, что хочется подчеркнуть, что ничего существенного (с точки зрения региона/состояния, к которому относится финальное состояние) уже произойти не может - только выход, причём это будет и выход из региона/состояния. Но оказалось, что в случае композитного ортогонального (в отличие от неортогонального) состояния появляется новая ситуация - часть регионов достигла финального состояния, а часть - нет.

Мне интересно, откуда появилась в UML такая трактовка? Уж не от неудавшегося сращивания диаграмм состояний с диаграммами деятельности в 1-й версии UML? Ведь в "математических" автоматах финальное состояние -- обычное состояние с дополнительным свойством, т. е. у математиков оно в каком-то смысле больше, чем обычное состояние, а не наоборот.

Так перемыть косточки UML у меня даже с коллегами на работе не получалось.

Цель - не наехать, а выбрать или скомпоновать для себя подходящее средство для использования. У меня нет большого опыта практического использования диаграмм состояний UML, а диаграмм классов - есть. И тут UML - явный лидер по возможностям, опережая и "сущность-связь", и Object Role Modeling, и EXPRESS, и других (хотя в отдельных аспектах может им уступать).

Это так, но, вероятно, придётся прописать такое положение в языке. Сделать это формально (на OCL) затруднительно.

Убрать из 14.5.8.6 первые 2 ограничения.

Сама нотация может обескураживать: несколько псевдосостояний предыстории  изображают одну предысторию и несколько меток для состояний, являющихся предысторией по умолчанию.

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

Мне кажется, что такая пометка состояния могла бы делаться не звеном из "вертолётной площадки", а тегом на самом состоянии. Хотя такой вариант, скорее всего менее нагляден, чем стандартный.

Когда-то такой знак "вертолётной площадки" и был тэгом на композитном состоянии (без входящих и исходящих переходов),  что означало, что любой повторный вход в композитное состояние означает продолжение с места прерывания. Потом стало ясно, что это слишком узко, что иногда надо продолжить, а иногда и начать по новой.

Мне интересно, откуда появилась в UML такая трактовка? Уж не от неудавшегося сращивания диаграмм состояний с диаграммами деятельности в 1-й версии UML? Ведь в "математических" автоматах финальное состояние -- обычное состояние с дополнительным свойством, т. е. у математиков оно в каком-то смысле больше, чем обычное состояние, а не наоборот.

В "математических" автоматах финальное состояние играет другую роль: если обработка последовательности сигналов завершилась в финальном состоянии, то последовательность "правильная".

Зачем же вмешиваться в столь длинную и детальную дискуссию? Тут надо глубоко проникнуть в проблему, которая двигает эту беседу. А это на самом деле не так просто. Потому ваша беседа воспринимается, как академическая. 

Убрать из 14.5.8.6 первые 2 ограничения.

Я думал о том, что затруднительно описать ограничение, которое бы сказало, что диаграмма "с душком" (например, из-за недетерминированного составного перехода, у которого несколько звеньев заканчиваются в разных исторических псевдосостояниях одного региона). Впрочем, такие сложности не связаны именно с множественностью исторических псевдосостояний, должен признать.

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

Попробую так. Конкретный синтаксис с несколькими предысториями допускает толкование, что для каждого способа входить в состояние по предыстории (в Вашем примере от 16.06 таких способов у State1 два -- левый и правый) есть отдельная память, ведущая независимую историю. Т. е. при входе слева срабатывает левая предыстория, справа -- правая. Если бы "вертолётная площадка" была одна, повода для такого толкования не возникало бы.

Когда-то такой знак "вертолётной площадки" и был тэгом на композитном состоянии (без входящих и исходящих переходов),  что означало, что любой повторный вход в композитное состояние означает продолжение с места прерывания. Потом стало ясно, что это слишком узко, что иногда надо продолжить, а иногда и начать по новой.

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

Общий недостаток нотации начальных и исторических псевдосостояний вижу в том, что для обозначения дефолтных состояний (начального по умолчанию, истории по умолчанию) используются звенья. Визуально такие звенья мало чем отличаются от обычных и хочется повесить на них триггер, к примеру. Но стандарт не велит. Если бы такие псевдозвенья выглядели бы не так, как обычные, запреты стандарта были бы подкреплены конкретным синтаксисом. Придумался простой способ достичь этого. Псевдопереходы из начальных и исторических псевдосостояний нужно рисовать пунктиром. Связать пунктир с невозможностью повесить триггер легко.

В "математических" автоматах финальное состояние играет другую роль: если обработка последовательности сигналов завершилась в финальном состоянии, то последовательность "правильная".

"Математическая" трактовка почти та же, что у протокольных диаграмм состояний. А протокольные финальные состояния нечем не отличаются от обычных.
К финальному состоянию стандарт привязывает специфический аспект -- генерацию события завершения для региона. Схожий с завершением, на мой взгляд, момент связан с терминацией (terminate-псеводостоянием). Только terminate прибивает всю машину. Представим, что есть два вида таких псевдосостояний: первый (обычный) -- для завершения региона, второй (со *) -- для завершения всей машины. Т. е. я хочу подвести к тому, что финальное состояние региона -- это, по смыслу, псевдосостояние, т. к. это условное обозначение.
Рассуждения о том, что финальное состояние -- стабильная вершина, как мне кажется, схоластичны. Если регион достиг финала, то нет никакой разницы, считаем ли мы "текущим" одно из его финальных состояний или никакое из его подсостояний, поскольку он завершён. Понятие стабильной вершины само по себе вызывает вопросы. Простое состояние без do-деятельности с переходом из него, запускаемым по завершению, стабильно лишь фиктивно. При работе машины оно проскакивается. Т. е. стабильность определяется работой автомата, а не на уровне синтаксиса. Псевдосостояния -- это спец. обозначения. Именно этим они отличаются от состояний. То, что псевдосостояния нестабильные вершины, не отделяет их от состояний (которые тоже могут быть нестабильны).

Конкретный синтаксис с несколькими предысториями допускает толкование, что для каждого способа входить в состояние по предыстории (в Вашем примере от 16.06 таких способов у State1 два -- левый и правый) есть отдельная память, ведущая независимую историю. Т. е. при входе слева срабатывает левая предыстория, справа -- правая. Если бы "вертолётная площадка" была одна, повода для такого толкования не возникало бы.

Когда "вертолётная площадка" одна, то и история одна, причём как она изменяется (до сих пор мы больше внимания уделяли тому, как история используется) тоже понятно: если выход через финальное состояние, то история обнуляется, если нет, то в историю записывается та конфигурация, из которой произошёл выход (в случае неглубокой истории из этой конфигурации будет использоваться только верхний уровень).
Если считать, что для каждого способа входить в состояние по предыстории есть отдельная память, то нужно определить как на каждую из этих "памятей" влияет выход из композитного состояния. На примере диаграммы: если произошёл выход из State1, конфигурация могла быть State2, а могла и State3. Как это повлияет на историю левого исторического и как это повлияет на историю правого исторического (ведь выход из State2 не означает, что вход был через левое историческое)? Может считать, что влияние оказывается на ту историю, через которую произошёл вход? Но вход мог произойти и без истории (в примере этого нет, но могло бы быть)!
Остаётся вариант, что история композитного состояния одна общая (это согласуется и с тем случаем, когда имеются по одному псевдосостоянию и глубокой и неглубокой истории - история у них общая).

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

Здесь в "площадку" звенья ни входят, ни выходят (правда это не Харел и не UML) http://matlab.exponenta.ru/stateflow/book1/2.php

Общий недостаток нотации начальных и исторических псевдосостояний вижу в том, что для обозначения дефолтных состояний (начального по умолчанию, истории по умолчанию) используются звенья. Визуально такие звенья мало чем отличаются от обычных и хочется повесить на них триггер, к примеру. Но стандарт не велит. Если бы такие псевдозвенья выглядели бы не так, как обычные, запреты стандарта были бы подкреплены конкретным синтаксисом. Придумался простой способ достичь этого. Псевдопереходы из начальных и исторических псевдосостояний нужно рисовать пунктиром. Связать пунктир с невозможностью повесить триггер легко.

Конкретный синтаксис это вообще субъективно. Тут бы с абстрактным синтаксисом (где всё сводится к "да" или "нет") разобраться.

"Математическая" трактовка почти та же, что у протокольных диаграмм состояний. А протокольные финальные состояния нечем не отличаются от обычных.

Я понимаю "математический" автомат, как что-то похожее на https://ru.wikipedia.org/wiki/Конечный_автомат

К финальному состоянию стандарт привязывает специфический аспект -- генерацию события завершения для региона. Схожий с завершением, на мой взгляд, момент связан с терминацией (terminate-псеводостоянием). Только terminate прибивает всю машину. Представим, что есть два вида таких псевдосостояний: первый (обычный) -- для завершения региона, второй (со *) -- для завершения всей машины. Т. е. я хочу подвести к тому, что финальное состояние региона -- это, по смыслу, псевдосостояние, т. к. это условное обозначение.
Рассуждения о том, что финальное состояние -- стабильная вершина, как мне кажется, схоластичны. Если регион достиг финала, то нет никакой разницы, считаем ли мы "текущим" одно из его финальных состояний или никакое из его подсостояний, поскольку он завершён. Понятие стабильной вершины само по себе вызывает вопросы. Простое состояние без do-деятельности с переходом из него, запускаемым по завершению, стабильно лишь фиктивно. При работе машины оно проскакивается. Т. е. стабильность определяется работой автомата, а не на уровне синтаксиса. Псевдосостояния -- это спец. обозначения. Именно этим они отличаются от состояний. То, что псевдосостояния нестабильные вершины, не отделяет их от состояний (которые тоже могут быть нестабильны).

Состояния могут быть нестабильными, а псевдосостояния нестабильны всегда.
В примере 2-я диаграмма - состояние State6 определяет 3 стабильные конфигурации ({State7, State9},{State7, final},{final, State9}) и одну нестабильную - {final, final}. А если не будет исходящего без триггера перехода из State6 - 4 стабильные? А если такой переход будет, но с условием (которое может и выполняться, и невыполняться) - и то проскакивается, то не проскакивается?

Остаётся вариант, что история композитного состояния одна общая (это согласуется и с тем случаем, когда имеются по одному псевдосостоянию и глубокой и неглубокой истории - история у них общая).

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

Здесь в "площадку" звенья ни входят, ни выходят (правда это не Харел и не UML)

Создателям Симулинка, вероятно, так было проще реализовывать симулятор. Они и junction превратили в choice.) Реализаторская точка зрения тоже имеет значение, вообще говоря.

Конкретный синтаксис это вообще субъективно.

В подкрепление этого тезиса можно вспомнить конкретные синтаксисы от каждого из "троих друзей" до того как их "подружили".)

Состояния могут быть нестабильными, а псевдосостояния нестабильны всегда.

Могу ещё раз сказать, что стабильность определяется при работе автомата. Можно построить пример [бессмысленного] автомата без стабильных состояний. Упор на стабильность не поясняет, зачем в язык были введены псевдосостояния. Введены они как спец. обозначения, и относиться к ним, как я полагаю, стоит именно так. Можно поправить стандарт, указав там "могут/всегда", но это мало что прояснит о запрете, к примеру, цеплять к псевдосостоянию входное и выходное действие. Оно -- вершина? Вершина. Мы через неё проходим? Проходим -- вон стрелочки идут. Значит, входим и выходим, но не задерживаемся, ведь она нестабильная вершина. И т. д. Если говорить, что псевдосостояние -- это спец. обозначение, что звено, входящее в него или исходящее из него -- не переход, то такое описание будет адекватнее, как мне кажется. Про стабильность/нестабильность можно говорить, рассматривая работу автомата, если это важно по каким-то [другим] причинам.
Если угодно, разница между псевдосостоянием и обычным состоит в том, что для того, чтобы покинуть состояние придётся "съесть" из очереди событие (даже если это событие завершения, которое автомат сам себе может подкладывать в очередь в тот момент, когда "хочет" его съесть). Покидание псевдосостояния происходит сразу без "съедания" события из очереди. Но ведь можно нагромоздить и такое, что при проходе сквозь псевдосостояние порождается событие его завершения, а звено из псевдосостояния должно рассматриваться как переход по этому порождаемому событию. Так мы нивелируем разницу между проскакиваемым состоянием и псевдосостоянием с точки зрения работы автомата.

В примере 2-я диаграмма - состояние State6 определяет 3 стабильные конфигурации ({State7, State9},{State7, final},{final, State9}) и одну нестабильную - {final, final}. А если не будет исходящего без триггера перехода из State6 - 4 стабильные? А если такой переход будет, но с условием (которое может и выполняться, и невыполняться) - и то проскакивается, то не проскакивается?

Я рассматриваю способы указывать, что в некоторых состояниях генерируется событие завершения региона. Это можно делать, рисуя от таких состояний (псевдо)звено к псевдосостоянию "крестик без *". ("Крестик со *" будет генерировать завершение всей машины.) Конструкция из состояния и "крестика" будет по смыслу похожа на стандартное финальное состояние, с той лишь разницей, что от обычного состояния можно рисовать переходы, а от финального нельзя, что в обычном состоянии может быть do-деятельность, а в финальном нельзя, входные/выходные действия -- аналогично. Т. е. генерация завершений может быть изображена спец. обозначением -- псевдосостоянием, соединённым с обычным состоянием, а не неполноценным финальным недосостоянием.
Генерацию завершения можно изображать как спец. действие, хотя это может быть не так наглядно.
Рассуждения о нестабильности финальных состояний были неточны, признаю. Можно пытаться считать, что, попав в финальное состояние региона, автомат генерирует событие завершения региона и текущим состоянием становится сам завершённый регион (по Харелу регионы -- состояния). В случае с несколькими финальными состояниями внутри региона, это неудобно, так как может быть важно в каком именно из них произошло завершение.

Другой вариант, что, если непонятно в какую память записывать, то записывать в обе.)

Дело в том, что всегда непонятно в какую память записывать, поэтому если записывать в обе,то обе памяти оказываются идентичными.

Вот у Харела предлагалось использовать в сторожевых условиях темпоральную логику, сведения о текущем состоянии в ортогональном регионе и т. п. В таком же духе можно от общей одной "вертолётной площадки" провести пунктиры к разным дефолтным предысториям и на пунктирах этих написать "сторожей", проясняющих выбор дефолтной предыстории.

Да, это формально допустимый вариант, но он требует введения переменной, которая будет содержать информацию для работы "сторожей". А переменная требует инициализации значения и ...(выше уже говорилось: "переменные сильно снижают наглядность диаграммы"). Другое дело, если переменные уже существуют для обслуживания автомата - например используются в каких-то деятельностях (entry, exit, do или на переходах).
По поводу пунктиров: они будут выражать невозможность повесить триггер, но есть и другие ограничения, например обязательное отсутствие сторожа и/или деятельности на переходе. Есть еще одно соображение (не против визуального выделения, а против именно пунктира) - когда рисуешь от руки на бумаге, то часто сначала ясно, что нужна соединительная линия, а только потом ясно, какого она типа. А превратить нарисованную сплошную в пунктирную достаточно затратно, уж лучше бы сделать какую-нибудь пометку. Но это опять про конкретный синтаксис

Дело в том, что всегда непонятно в какую память записывать, поэтому если записывать в обе,то обе памяти оказываются идентичными.

Каждый выход происходит после какого-то входа. Часть входов происходит по левому пути (через левую память), часть по правому. Через какую память входили, в ту и пишем.

Да, это формально допустимый вариант, но он требует введения переменной, которая будет содержать информацию для работы "сторожей". А переменная требует инициализации значения и ...(выше уже говорилось: "переменные сильно снижают наглядность диаграммы"). Другое дело, если переменные уже существуют для обслуживания автомата - например используются в каких-то деятельностях (entry, exit, do или на переходах).

Харел использовал "системные переменные", которые описывают [текущую | прошлую] конфигурацию состояний автомата. Они не вводятся автором диаграммы. Пример стандартной "системной переменной" без имени -- время -- в событиях времени at(12pm), after(1ns).

По поводу пунктиров: они будут выражать невозможность повесить триггер, но есть и другие ограничения, например обязательное отсутствие сторожа и/или деятельности на переходе. Есть еще одно соображение (не против визуального выделения, а против именно пунктира) - когда рисуешь от руки на бумаге, то часто сначала ясно, что нужна соединительная линия, а только потом ясно, какого она типа. А превратить нарисованную сплошную в пунктирную достаточно затратно, уж лучше бы сделать какую-нибудь пометку. Но это опять про конкретный синтаксис

Думаю, что, разделяя звенья и псевдозвенья, можно договориться о том, что на самом деле запрещать на псевдозвене (и не запрещать сторожей и эффекты просто ради запрета). Пунктиры взяты по аналогии с зависимостями с диаграмм классов. Там-то они прижились.

P. S. Выходила книга Бьянкуцци, Уорден. Пионеры программирования. В ней помимо всего прочего "трое друзей" рассказывают про историю UML, критикуют и предсказывают ему будущее. Pdf-ка гуляет по сети.

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

Каждый выход происходит после какого-то входа. Часть входов происходит по левому пути (через левую память), часть по правому. Через какую память входили, в ту и пишем.

Ответ:

Если считать, что для каждого способа входить в состояние по предыстории есть отдельная память, то нужно определить как на каждую из этих "памятей" влияет выход из композитного состояния. На примере диаграммы: если произошёл выход из State1, конфигурация могла быть State2, а могла и State3. Как это повлияет на историю левого исторического и как это повлияет на историю правого исторического (ведь выход из State2 не означает, что вход был через левое историческое)? Может считать, что влияние оказывается на ту историю, через которую произошёл вход? Но вход мог произойти и без истории (в примере этого нет, но могло бы быть)!

Правила для обслуживания нескольких исторических псевдосостояний должны быть такими, чтобы если будет только одно историческое псевдосостояние обслуживание происходило так, как это описано в стандарте или у Харела. Я вижу 2 варианта:

• любой выход оказывает влияние на все истории
• выход оказывает влияние только на историю, по которой произошёл вход, а если вход произошёл без истории, то на все истории

Критерием, который мог помочь при выборе между этими вариантами, могло быть описание поведения, если композитное состояние одновременно имеет и глубокую, и неглубокую историю. Но у Харела таких случаев я не нашел, и в стандарте тоже (хотя в 14.5.8.6 первые 2 ограничения записаны так, что это возможно). Моя позиция - любой выход оказывает влияние на все истории (но подкрепить её нечем).

P. S. Выходила книга Бьянкуцци, Уорден. Пионеры программирования. В ней помимо всего прочего "трое друзей" рассказывают про историю UML, критикуют и предсказывают ему будущее. Pdf-ка гуляет по сети.

Читал: объясняет, почему плохо, но неясно как будет хорошо.

Ответ:

Я недопонимаю. Картинка в голове такая. Если входим через левую/правую память, то сразу пишем в неё подсостояние, в котором оказались (глубина вложения подсостояния зависит от глубины истории). [Вообще говоря, не пишем, т. к. оно там и так лежит.] Вытираем записанное при смене подсостояния на нужном уровне глубины, пишем новое. Дошли до финального -- вытираем (+ вписываем предысторию по умолчанию либо начальное по умолчанию). Вышли -- предысторией стало то, что записали последним. Если входим не через левую/ правую память, то те же самые действия выполняем с каждой памятью (предварительно очищая, если не пуста).
Ваш пример мне не ясен, так как в нём лишь часть картинки -- как выходим.

Читал: объясняет, почему плохо, но неясно как будет хорошо.

По мне, в большей степени, объясняет, что у каждого в голове своя порода тараканов.)

Критерием, который мог помочь при выборе между этими вариантами, могло быть описание поведения, если композитное состояние одновременно имеет и глубокую, и неглубокую историю. Но у Харела таких случаев я не нашел, и в стандарте тоже (хотя в 14.5.8.6 первые 2 ограничения записаны так, что это возможно). Моя позиция - любой выход оказывает влияние на все истории (но подкрепить её нечем).

Необязательно. Можно считать, что разноуровневые истории работают совместно, а одноуровневые независимы.) Не то чтобы я настаиваю на множественности/независимости памятей. Речь скорее о соответствии между визуальным представлением и идеями, которые оно отображает. Если история/память одна, то и "вертолётная площадка" одна. Если несколько вариантов предыстории, то несколько элементов обозначающих эти варианты (а не несколько "площадок"). Разумно, если отдельное отображение имеется для памяти и отдельное -- для предысторий по умолчанию. В стандарте для второго служит [псевдо]звено. Значит, для первого -- "площадка". Отсюда "площадка" одна, псевдозвеньев несколько. Такая логика.

Необязательно. Можно считать, что разноуровневые истории работают совместно, а одноуровневые независимы.)

Недопустимое сочетание: пусть есть одна глубокая и две неглубокие истории - получается глубокая совместна с каждой неглубокой, а неглубокие между собой нет! Допустимы сочетания:

• разноуровневые истории работают совместно, и одноуровневые совместно (одна общая история на все "вертолётные площадки")
• разноуровневые истории работают независимо, а одноуровневые совместно(одна общая история на все "глубокие" "вертолётные площадки" и одна общая история на все "неглубокие" "вертолётные площадки")
• разноуровневые истории работают независимо, и одноуровневые независимо (своя история на каждую "вертолётную площадку")

Не то чтобы я настаиваю на множественности/независимости памятей. Речь скорее о соответствии между визуальным представлением и идеями, которые оно отображает. Если история/память одна, то и "вертолётная площадка" одна. Если несколько вариантов предыстории, то несколько элементов обозначающих эти варианты (а не несколько "площадок"). Разумно, если отдельное отображение имеется для памяти и отдельное -- для предысторий по умолчанию. В стандарте для второго служит [псевдо]звено. Значит, для первого -- "площадка". Отсюда "площадка" одна, псевдозвеньев несколько. Такая логика.

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

Картинка в голове такая. Если входим через левую/правую память, то сразу пишем в неё подсостояние, в котором оказались (глубина вложения подсостояния зависит от глубины истории). [Вообще говоря, не пишем, т. к. оно там и так лежит.] Вытираем записанное при смене подсостояния на нужном уровне глубины, пишем новое. Дошли до финального -- вытираем (+ вписываем предысторию по умолчанию либо начальное по умолчанию). Вышли -- предысторией стало то, что записали последним. Если входим не через левую/ правую память, то те же самые действия выполняем с каждой памятью (предварительно очищая, если не пуста).

Как-то не очень хорошо выглядит - при одних входах работаем ровно с одной памятью, а при других - со всеми памятями. Да и что называем "входом" - пересечение границы композитного состояния снаружи внутрь, которое заканчивается на "вертолётной площадке" или ещё где-нибудь? А как воспринимать звено, которое заканчивается на "вертолётной площадке", но не пересекает границы композитного состояния (Harel "STATECHARTS: A VISUAL FORMALISM FORCOMPLEX SYSTEMS*" Fig.14)? Попутно вопрос по этой диаграмме: вместо использования конструкции с историческим псевдосостоянием можно завести внутренний переход в состоянии update (хотя бы в UML)?