106

UML SysML и пр. / Re: Переход от псевдосостояния истории

« : 13 Апреля 2017, 16:59:45 »

Ещё один взгляд на историю (синтаксис и семантика "вертолётной площадки") http://programming-lang.com/ru/comp_programming/buch/0/j73.html

107

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 13 Апреля 2017, 16:49:25 »

К многовходовости и циклам choice: http://matlab.exponenta.ru/stateflow/book1/3.php (правда это не UML).

108

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 11 Апреля 2017, 21:17:07 »

1. Да, по стандарту.

2. Нет. Если State1 и/или State2 -- junction'ы, то прежде следует преобразовывать их. Если State1 и/или State2 -- не junction'ы, и State3 -- choice, то [если мы верим в одновходовые choice] State3 дублируется State3bis и мы получаем:
State1 --[guard1 && guard2]/act1, act3-->State3--> [тут ветки State3]
State2 --[guard2 && guard3]/act2, act3-->State3bis--> [тут ветки State3]

3. Если State2 = State3 и эта вершина choice, то мы получаем:
State1 --[guard1 && guard2]/act1, act3-->State3--> [тут нерефлексивные ветки State3]
к State3 дорисовываем дополнительную ветку, соответствующую одному витку цикла:
State3 --[guard2 && guard3]/act2, act3-->State3bis--> [тут нерефлексивные ветки State3]
к State3bis дорисовываем дополнительную ветку, соответствующую двум виткам цикла:
State3bis --[guard2 && guard3]/act2, act3-->State3bisbis--> [тут нерефлексивные ветки State3]
к State3bisbis дорисовываем ...
т. е. выращиваем бесконечное дерево переходов-звеньев.

Одновходовость choice - это единственная причина необходимости State3bis и т.п. или есть ещё и другие?

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

А можно считать ошибкой недостижимость фрагментов диаграммы состояний, хотя бы из соображений минимизации диаграммы. Некоторые так и предлагают http://www.softcraft.ru/auto/switch/umlswecl/umlswecl.pdf стр.7-9

109

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 11 Апреля 2017, 10:28:05 »

Дело не в склеивании как таковом. При удалении junction мы вместо одного сложного перехода получаем несколько простых, решенных статически. Тут так не удастся: либо создастся дубль choice со звеном одновременно входящим и выходящим из него (и это будет его единственный вход); либо создастся бесконечное количество "простых" переходов: с одним, с двумя, с тремя, ... с N, ... choice'ами без "рефлексивного звена". Отвечая я мысленно дорисовываю действия к Вашему примеру, т. к. обеднённый частный случай, к. м. к. не показателен.

Попробуем разбираться по шагам.

• Во вложении эквивалентные конструкции?
• Эквивалентность сохраняется, если вместо state1, state2, state3 использовать псевдосостояния choice и junction?
• Эквивалентность сохраняется, если какие-то из state1, state2, state3 представляют собой одну и ту же вершину?

Разрешено всё, что не запрещено.) Я не знаю. Мне кажется, в попытках определять ill- и well formed создатели стандарта UML пока не преуспели.

Может пришло время явно обозначить, что речь идет не столько о том, что есть в стандарте, как о том, что там должно быть.
Можно применить аналогию: Заказчик составил материал, в котором, по его мнению, есть всё необходимое для Разработчика, но на самом деле предстоит  с помощью Аналитика получить новый материал, где действительно будет всё необходимое для Разработчика.

110

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 10 Апреля 2017, 09:52:58 »

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

Звено от junction к choice не обладает действиями, поэтому склеивая звенья-половинки (и действия на них) получим те же действия, что и на другой половинке.
Звено от junction к choice не обладает сторожем, что равносильно постоянной ИСТИНЕ, поэтому склеивая звенья-половинки и перемножая сторожей получим того же сторожа, что и на другой половинке.

В общем случае, не надо. Ведь бывают недостижимые choice. [И чего они в OCL требуют, чтобы были входящие звенья? Из текстового описания не следует, что они должны быть для well formed. Правда, придётся помучиться, чтобы отличить начальное псевдосостояние от junction без входов.))]

А возможны ли недостижимые вершины для well formed? Понимаю, что инструмент (типа EA) их должен поддерживать - как иначе сохранить промежуточный результат работы над диаграммой/моделью, но в конечном результате им нет места!

111

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 08 Апреля 2017, 20:03:19 »

Будет ли замещающая конструкция работать при ориентированном цикле из звеньев, включающем исходный многовходовый choice?

Как я понимаю - во вложении.

Пункт 1 -- лишь рекомендация стандарта (не согласующаяся с OCL, т. к. тогда бы выходов было >1).

Пойдем по шагам - надо ли гарантировать, что условие хотя бы одного выходящего из choice звена должно быть истинным?

112

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 07 Апреля 2017, 13:43:15 »

В поддержку choice со множественными входными звеньями. Вместо choice со множественными входными звеньями сделаем junction с теми же входными звеньями расположенное в том же состоянии, что и choice, а от junction к choice сделаем звено без события, сторожа и действий - получается вполне допустимая конструкция, которая работает точно так же.

113

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 06 Апреля 2017, 19:44:56 »

Ничего лучшего не придумал, кроме как накапливать и согласовывать факты про choice.

• ровно одно из выходящих звеньев должно быть с else (наиболее простой способ гарантировать выход из choice)
• выходящие звенья имеют guard и не имеют trigger
• имеется хотя бы одно входящее звено

114

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 05 Апреля 2017, 08:39:03 »

Замечу, что допустимы на основе 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 раза

Обе мне не нравятся (хотя Харел это Харел).

115

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 03 Апреля 2017, 17:19:13 »

и [тем более] циклит рефлексивным звеном.

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

Кстати или нет, рядом висит ограничение про то, что из начального псевдосостояния выходит неболее чем одно звено. Интересно, что имели в виду авторы стандарта под начальным псевдосостоянием без выходящего звена?)

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

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

Если состояние "проходное", то entry и exit сливаются в одно действие, и могут быть записаны как только entry (с пустым exit) или как только exit (с пустым entry) - ценность снижается.

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

Можно более точную ссылку?

116

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 03 Апреля 2017, 12:50:18 »

Радо новой встрече.

Я тоже!

Choice одновходовый, а "неустойчивое" состояние может иметь столько входящих переходов, сколько нужно (в том числе рефлексивные), а также действия по входу и по выходу, которых choice лишён.

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'ами условия-части проверяются "динамически"".
Что касается действий по входу и выходу:

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

С junction'ами все действия по выходу выполняются после проверки сторожевых условий, составленных из условий-частей на звеньях, составляющих композитный переход. А действия по входу -- после выполнения композитных действий по переходу, составленных из действий-частей на звеньях. С choice'ами условия-части проверяются "динамически" (цитирую стандарт), т. е. перед проверкой будут выполнены некоторые действия по выходу и действия-части на ранее пройденных звеньях. Поэтому расположение junction'ов неважно, но важно пересечение звеньями границ состояний. Например, два нижних junction'а можно поместить в St01, а два верхних -- в St0. Смысл диаграммы не изменится, т. к. звенья сохранят свою топологию. Перемещение choice'ов изменит поведение автомата. Также поведение изменится, если звено выгнется и пересечёт дополнительно какую-то границу.

Спасибо, мне стало понятно.

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

Есть версия, что стандарт ошибается, говоря про "глубже всех", годится любой, содержащий начало и конец. В примере (для [guard2]/act2) это регион, описывающий весь автомат (по стандарту каждый регион относится или к какому-то состоянию, или к автомату вцелом)

117

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 02 Апреля 2017, 11:48:25 »

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

Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому.

не понял

Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.

В метамодели Transition имеет обязательное значение container:Region. Оно должно подчинять и вход и выход, и именно по цепочкам до него происходят пересечения границ сначала изнутри-наружу, а  потом снаружи-внутрь.

118

UML SysML и пр. / Re: Как указать что человек работает в нескольких компаниях (UML, кратность)?

« : 24 Ноября 2016, 22:38:50 »

Может ли человек иметь несколько должностей в одной компании (может ли Иванов иметь должность "Воспитатель" в "Детский сад №14" и иметь должность "Руководитель кружка" в том же "Детском саду №14")?
Если да и должность понимается как трудовая функция, то первая диаграмма из предыдущего сообщения.
Если да и должность понимается как штатная единица, то диаграмма из самого первого сообщения. Из-за кратности ровно 1 в ассоциации от Должности к Человеку отражаются только заполненные штатные единицы.

119

Примеры / Re: Рефакторинг диаграммы состояний

« : 10 Ноября 2016, 11:49:18 »

размер примера не даёт в достаточной мере оценить размер выгоды, получаемой после рефакторинга

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

120

Примеры / Re: Рефакторинг диаграммы состояний

« : 08 Ноября 2016, 20:43:26 »

Прием с "вертолётной площадкой" подсмотрен у Харела (STATECHARTS: A VISUAL FORMALISM FOR COMPLEX SYSTEMS - fig.14,  fig.15, fig.34).
Поскольку композитное состояние во вложении 3 "искусственное" (не имеет ни входной, ни выходной деятельности), пара выход-вход ничего не меняет, то есть можно и "крючком".
В данной теме псевдосостояние истории не цель, а только средство - если есть возможность обойтись, то и ладно.