Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
почему outgoingtransition - это не transition?outgoingtransition - это transition, но на диаграмме этого сразу не видно, а хотелось бы!
begintransaction - что это за понятие? и не кажется ли вам, что оно выпадает из общей сравнительной классификации:По UML-стандарту начальный переход это подвид внешнего перехода, хотя некоторые UML-инструменты имеют визуальный элемент, который объединяет и начальное состояние, и переход из него. Но в данной теме хотелось обсуждать не это, а диаграммирование конкретной ситуации, а названия классов могли быть просто a, b, c, d, e, f.
начальный переход
внешний переход
внутренний переход
и разве начальный переход не подвид внешнего перехода?
Это понятно. Но в том же ключе можно назвать элементы диаграмм классов вершинами [графа, которым является ДК].В стандарте используется Vertex, которое переводится как "вершина", вот и стал так называть.
В 2 провокационно хотелось пунктирную часть видеть исходящей из середины сплошной (на манер пунктира класса ассоциации).Не смог (инструмент EA12).
Зачем требовать триггер именно на первые звенья? Может быть, требовать, что бы не было более одного триггера на любом из возможных путей?Именно такой вывод и хотел получить
Мудрёно.Переходы из одной Vertex не должны "пересекаться" - сработать может только один переход. Но из некоторых Vertex (например начальное псевдосостояние) обязательно надо выйти. Есть 2 способа это обеспечить:
Это понятно, но зачем выделяется такая категория? Очевидно же, что автомат лишь визуально состоит из вершин и звеньев, а на самом деле определяет правила переключения между конфигурациями состояний и сопутствующее поведение. У отделённого сиамского близнеца диаграмм состояний -- диаграмм деятельности -- контрольные узлы никто не называет псевдоузлами, например. И не говорит о стабильности.Зачем вводится понятие "вершина", которое объединяет понятия "состояние" и "псевдосостояние"? У состояний и псевдосостояний много общего (например каждое звено исходит от ровно одного из них и приходит ровно к одному из них).
Заручимся тем, что Харел придумал чистить предысторию спец. действием. По его плохому примеру разрешим проверять, пуста ли предыстория в стороже. Тогда, в Вашем примере можно рисовать двузубец с choice, первый зуб которого идёт в "вертолётную площадку" (одну! общую!) и имеет сторожа [not EmptyHistory], второй идёт в предысторию по умолчанию и имеет сторожа [else]. Прелесть в том, что можно рисовать трезубец, n-зубец и описывать условные дефолтные предыстории.Отразил, как понял в 1 и 2 вложении. Вложение 3 - вариант с запоминанием в переменной c откуда пришли, вложение 4 - провокационная версия того же.
Другой способ менее выразительный -- разрешить переходам в предысторию иметь второе дополнительное (пунктирное:) остриё, указывающее на дефолтную предысторию для этого перехода. Основное (сплошное) остриё идёт только в "площадку" (которая одна, общая).
Такое прочтение возможно. С другой стороны можно видеть (в тексте, не в метамодели!) составные переходы (compound transition) и всюду дальше их первого упоминания подозревать, что транзишэнами называют и их и звенья.Беда стандарта, что в текстовой части смешаны и синтаксис, и семантика (это ещё не беда - так многие источники делают: действительно при первоначальном изучении только так и можно что-то понять), и при этом один и тот же термин "переход" используется и при описании синтаксиса, и при описании семантики, а часть, которая должна однозначно определить синтаксис - метамодель, этой цели не достигает.
Довольно бессмысленно, на мой взгляд, запрещать в стандарте проводить из начального псевдосостояния несколько исходящих звеньев, но разрешать(?) рисовать хареловский эквивалентный им N-зубец с choice/junction.Согласен, всё равно такой N-зубец надо проверять на полноту выходов. Вложения 3 и 4 содержат пример того же для исторического псевдосостояния. Может это всё для того, чтобы только после choice/junction проверять полноту выходов?
Хорошо бы описать, что такое вершина, что общего между разными типами вершин, и обосновать дискриминацию разных типов вершин.Вершина (Vertex) = состояние (State) + псевдосостояние (Pseudostate). Потом, при рассмотрении вложенных автоматов (StateMachine), возможно добавятся и ссылки на точки соединения (ConnectionPointReference). А такое дискриминация вершин?
Может быть, рассмотреть другой способ?Какой (кроме junction/choice после звена из "вертолётной площадки")?
Как мы обсуждали, в стандарте нет явной градации на звенья и переходы. Диаграмму можно трактовать так, что из начального состояния выходит один составной переход, на котором есть сторожа.В описании (диаграмме) автомата есть только звенья (Transition). У каждого звена ровно 1 вершина-исто(чни)к и ровно 1 вершина-цель.
Я уверен в ответе 2 (с уточнениями). Обоснование видел в "A Crash Course in UML State Machines" M. Samek. Там есть пример с перекрывающимися разноуровневыми локальными переходами у вложенных состояний.Принято
Но в оперение-"площадку" входит переход.В общем случае - не менее одного перехода. Причём это правило действует на все вершины (состояния и псевдосостояния), кроме начального (у начального своё правило - если оно относится к композитному состоянию, не менее одного перехода к этому композитному состоянию). Смысл - любая вершина должна быть достижимой.
Т. е. она -- вершина. А зачем одну общую предысторию представлять несколькими разными вершинами?Для того, чтобы показать разные варианты поведения (когда историческая память не содержит никакого значения).
Как глазом увидеть, что она общая? Почему видимые несколько "площадок" надо в голове объединять? Разве это наглядно?То, что она общая - заложено в семантике (в одной из возможных семантик).
В тех же статьях, кстати, есть двузубцы с choice/junction, растущие из начальных состояний. Привет от Харела составителям стандарта [и мне].))Если имеется в виду Fig. 18. из "The Rhapsody Semantics of Statecharts", то всё нормально - из начального псевдосостояния ровно одно звено, без триггера и условия.
у него там, как я понял, идея в том, чтобы параметризовать эффект такого перехода (в зависимости от состояния апдейтить разные переменные). Почему там важно оставаться внутри композитного состояния, я не уяснил, но пусть так. В UML придётся завести по локальному переходу со своим эффектом в каждом подсостоянии. Если эффект одинаков, то локальный переход может быть общим и лежать в композитном состоянии.Сформулирую вопрос по другому - если композитное состояние имеет внутренний переход, то это:
Необязательно. Можно считать, что разноуровневые истории работают совместно, а одноуровневые независимы.)Недопустимое сочетание: пусть есть одна глубокая и две неглубокие истории - получается глубокая совместна с каждой неглубокой, а неглубокие между собой нет! Допустимы сочетания:
Не то чтобы я настаиваю на единственности/зависимости памятей. Но для меня "вертолётная площадка" - это не признак "отдельной" истории, а признак обращения к "общей" истории, а звено, выходящее из "вертолётной площадки" - указание что делать, если в этой "общей" истории ничего не записано (или записано "особое" значение).
Не то чтобы я настаиваю на множественности/независимости памятей. Речь скорее о соответствии между визуальным представлением и идеями, которые оно отображает. Если история/память одна, то и "вертолётная площадка" одна. Если несколько вариантов предыстории, то несколько элементов обозначающих эти варианты (а не несколько "площадок"). Разумно, если отдельное отображение имеется для памяти и отдельное -- для предысторий по умолчанию. В стандарте для второго служит [псевдо]звено. Значит, для первого -- "площадка". Отсюда "площадка" одна, псевдозвеньев несколько. Такая логика.
Картинка в голове такая. Если входим через левую/правую память, то сразу пишем в неё подсостояние, в котором оказались (глубина вложения подсостояния зависит от глубины истории). [Вообще говоря, не пишем, т. к. оно там и так лежит.] Вытираем записанное при смене подсостояния на нужном уровне глубины, пишем новое. Дошли до финального -- вытираем (+ вписываем предысторию по умолчанию либо начальное по умолчанию). Вышли -- предысторией стало то, что записали последним. Если входим не через левую/ правую память, то те же самые действия выполняем с каждой памятью (предварительно очищая, если не пуста).Как-то не очень хорошо выглядит - при одних входах работаем ровно с одной памятью, а при других - со всеми памятями. Да и что называем "входом" - пересечение границы композитного состояния снаружи внутрь, которое заканчивается на "вертолётной площадке" или ещё где-нибудь? А как воспринимать звено, которое заканчивается на "вертолётной площадке", но не пересекает границы композитного состояния (Harel "STATECHARTS: A VISUAL FORMALISM FORCOMPLEX SYSTEMS*" Fig.14)? Попутно вопрос по этой диаграмме: вместо использования конструкции с историческим псевдосостоянием можно завести внутренний переход в состоянии update (хотя бы в UML)?
Каждый выход происходит после какого-то входа. Часть входов происходит по левому пути (через левую память), часть по правому. Через какую память входили, в ту и пишем.Ответ:
Если считать, что для каждого способа входить в состояние по предыстории есть отдельная память, то нужно определить как на каждую из этих "памятей" влияет выход из композитного состояния. На примере диаграммы: если произошёл выход из State1, конфигурация могла быть State2, а могла и State3. Как это повлияет на историю левого исторического и как это повлияет на историю правого исторического (ведь выход из State2 не означает, что вход был через левое историческое)? Может считать, что влияние оказывается на ту историю, через которую произошёл вход? Но вход мог произойти и без истории (в примере этого нет, но могло бы быть)!Правила для обслуживания нескольких исторических псевдосостояний должны быть такими, чтобы если будет только одно историческое псевдосостояние обслуживание происходило так, как это описано в стандарте или у Харела. Я вижу 2 варианта:
P. S. Выходила книга Бьянкуцци, Уорден. Пионеры программирования. В ней помимо всего прочего "трое друзей" рассказывают про историю UML, критикуют и предсказывают ему будущее. Pdf-ка гуляет по сети.Читал: объясняет, почему плохо, но неясно как будет хорошо.
Другой вариант, что, если непонятно в какую память записывать, то записывать в обе.)Дело в том, что всегда непонятно в какую память записывать, поэтому если записывать в обе,то обе памяти оказываются идентичными.
Вот у Харела предлагалось использовать в сторожевых условиях темпоральную логику, сведения о текущем состоянии в ортогональном регионе и т. п. В таком же духе можно от общей одной "вертолётной площадки" провести пунктиры к разным дефолтным предысториям и на пунктирах этих написать "сторожей", проясняющих выбор дефолтной предыстории.Да, это формально допустимый вариант, но он требует введения переменной, которая будет содержать информацию для работы "сторожей". А переменная требует инициализации значения и ...(выше уже говорилось: "переменные сильно снижают наглядность диаграммы"). Другое дело, если переменные уже существуют для обслуживания автомата - например используются в каких-то деятельностях (entry, exit, do или на переходах).
