331

ПО Аналитика / Re: Управление изменениями требований

« : 03 Мая 2017, 13:24:57 »

Ну вот, задвигалось. Благодарю за участие в теме.
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
И есть методика, поясняющая, что исполнитель внутри [бизнес-]системы и элемент контекста [бизнес-]системы aka actor -- не одно и то же. Но зачем, всё это, если можно изобрести какую-то мимикрию под стандартные обозначения и связывать с ними свои собственные смыслы? Красоту подобных визуализаций может оценить лишь тот, кто входит в соответствующее "языковое гетто".
А почему это не UML, если автор, это нарисовавший, считает, что рассказывает про UML?

332

ПО Аналитика / Re: Управление изменениями требований

« : 03 Мая 2017, 01:34:34 »

Само пошутило, само поржало. 
Небезызвестный Kirill Fakhroutdinov считает, что это " typical misconception", что я перевожу на язык тутошней планеты как "популярные грабли".

Кто в этот раз напишет "+100500 к граблям"? Вопрос риторический.

333

Для всех / Re: Реализация и документы

« : 30 Апреля 2017, 05:43:45 »

Подскажите пожалуйста, какие вообще диаграммы для чего используются?
Если уже есть развернутый ответ на форуме, укажите где.

Развернутый ответ есть здесь:
http://www.uml-diagrams.org/uml-25-diagrams.html

334

ПО Аналитика / Re: Управление изменениями требований

« : 29 Апреля 2017, 21:50:35 »

Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html

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

335

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

« : 19 Апреля 2017, 22:39:47 »

Для меня если условие на исходящем звене проверяется не заранее, а по достижении, то это по сути - choice.

Я так поняло, что если бы были действия (transition action) на циклическом звене, то цикла бы было как бы два. Сначала перед выходом из состояния ходили бы и считали в уме круги, а уж потом бы вышли и сколько насчитали, столько бы раз запустили transition action. Жуткий гибрид.)

336

Для всех / Re: Помогите создать классовую диаграмму

« : 15 Апреля 2017, 11:09:36 »

Можно заметить, что сделанное EA больше похоже на db.png, чем Ваша диаграмма классов. И сделать из этого выводы.
До вторника можно успеть нагуглить книжку Джима Коналлена с примерами диаграмм, похожих на те, что Вам нужны.

337

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

« : 14 Апреля 2017, 23:33:41 »

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

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

Конечно, если диаграмма рисуется для чтения человеком, то "мертвое" лучше с неё убрать.

Ссылка на Матлаб прекрасна. Там и про history junction замечательно написано. Только переводчик ленивый.) Пример без действий, и локальный переход может быть нелокальным -- смысл не меняется. Есть полный пример с действиями: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant35.html#1028350
Ну и "вкуснятинка" вроде того, что "вертолётной площадки" достаточно, переход в неё может не вести, любой переход к границе суперсостояния на самом деле ведёт к ней (если история не пуста).
И это не choice'ы, это такие junction'ы.) Цикл отработает до выхода из состояния)): http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant40.html
Их можно ставить всюду, даже после начального псевдосостояния. Начальных может быть несколько: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant31.html
А иногда их можно использовать для того, чтобы вернуться назад как ни в чём не бывало: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant45.html

338

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

« : 14 Апреля 2017, 23:05:44 »

Буч как первоисточник кучи ошибок, это здорово. Может быть, всё дело в различиях версий UML?

339

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

« : 11 Апреля 2017, 12:57:27 »

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 дорисовываем ...
т. е. выращиваем бесконечное дерево переходов-звеньев.
Это если придерживаться духа стандартных примеров по использованию junction и choice.
Либо, как предлагалось, превращаем choice в обычное состояние.

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

340

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

« : 10 Апреля 2017, 15:58:50 »

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

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

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

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

341

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

« : 10 Апреля 2017, 02:52:41 »

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

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

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

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

342

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

« : 07 Апреля 2017, 22:31:22 »

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

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

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

343

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

« : 07 Апреля 2017, 22:28:28 »

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

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

344

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

« : 05 Апреля 2017, 22:07:55 »

Реализаторам choice со множественными входными звеньями точно не понравится. Miro Samek со state-machine.com писал на тамошнем старом форуме, что branch'ующий choice "coded as if (...) else if (...) ... else ...". Очевидно, что стандартный choice приведёт к чему-то другому (по-моему, к проходным состояниям и к коротким переходам-звеньям между ними). 

345

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

« : 05 Апреля 2017, 21:47:46 »

Я не берусь так сразу подобрать убийственный аргумент.) Немного странно, что choice со многими входными звеньями и одним выходным всё ещё будет choice'ом, а не каким-нибудь merge'ом. Как заклинание в тексте branch-branch, а OCL вдруг открывает перспективу соорудить на choice'ах вложенную псевдодиаграмму деятельности, описывающую динамическую "передачу управления" между состояниями. Я полагало, что branch'и как раз для того, чтобы не было ориентированных циклов внутри составных переходов. Тут бы слово/пример от какого-то гуру позволил бы сжиться с таким моим недопониманием.

Не стоит досадовать. Ваше участие очень многое даёт мне. Раскрываете шире мне глаза.

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

Против одного выхода из choice могу указать примеры со http://www.state-machine.com/ где нестандартная, но похожая на стандартную нотация и придумано, что не бывает простых переходов со сторожами. Вместо них рисуется составной через choice с одним выходящим звеном.

см. https://www.state-machine.com/qm/sm_tran.html
По стандарту B -- это почти всегда ill formed диаграмма, не эквивалентная A. Небранчующий choice даёт поводы рисовать такое. Наброс слабый, но как первый подход, прошу зачесть.)
Пример, с другой стороны интересен тем, как реализация влияет на язык.