91

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« Последний ответ от [прилетело НЛО и...] 31 Января 2022, 15:39:02 »

Пример интересный, поэтому лезу в раскоп.
По идее (если ориентироваться на картинки из стандарта), внутри должны быть роли (и/или части), которые не являются классами. То есть класс Период должен лежать снаружи, а его имя должно использоваться как тип у роли/части.
То, что названо типом периода, на мой взгляд, больше похоже на последовательность периодов, т. е. на некоторый контейнер.
Вероятно, у периода всегда есть обе оконечные точки, и если периоды входят в состав некоторого контейнера, то одна из точек является выводимой.
Вероятно, периоды не тянут на классы, а являются структурированными типами (<<datatype>>). Например, в примере дубли одного и того же периода, входящие в состав разных контейнеров должны быть различными экземплярами или одним и тем же экземпляром?

92

UML SysML и пр. / Re: Связь между диаграмми последовательности и диаграммами состояний

« Последний ответ от [прилетело НЛО и...] 26 Января 2022, 18:44:38 »

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

Пусть на ДП объект X посылает объекту Y сообщение mes(). ... в ДС X есть состояние с входным эффектом mes() (/entry mes() ).

Первое, отправка сообщения Y.mess() может быть в любом эффекте, не обязательно в эффекте входного действия.
Второе, ДП может моделировать трассу, на которой X и Y не взаимодействуют или взаимодействуют так, что вызов Y.mess() не происходит.
Третье. Y может игнорить отправляемые ему вызовы Y.mess(). Значит, неточно и это:

...для некоторого состояния в ДС Y есть переход по событию mes().

93

Примеры / Re: Жизненный цикл заявки. Диаграмма состояний. Пример

« Последний ответ от [прилетело НЛО и...] 26 Января 2022, 18:31:26 »

Если верить стандарту UML (в текущей версии), то:
Class
A
|
Behavior
A
|
StateMachine
Если верить в принцип Барбары Лизковы, то StateMachine-ы можно соединять обобщениями (и ассоциациями). Возможно, что авторы нотации расширяемых StateMachine не верят в ПрБЛ или в стандарт и потому изобрели свой велосипед.
Выше верно отмечено, что State не может участвовать в обобщениях. Но у некоторых State может быть вложенная StateMachine. А вот она-то может участвовать в обобщениях и её потомок может рассматриваться как сама вложенная StateMachine. От открывающихся перспектив по построению конструкций, которые затруднительно будет осмыслить, у меня захватывает дух. Поэтому умолкаю.
Ещё один повод замолчать в том, что ни один из участников ветки так ничего и не нарисовал. Уверено, что расширяемые состояния для моделирования не потребовались бы.
Дальше немного трындежа:
+ Пользователь, которого надо чекать, может передаваться как параметр в сообщении. Сторожевое условие -- проверка параметра сообщения на равенство со ссылкой на пользователя из самой заявки -- вполне себе всё моделирует.
+ Так как на диаграмме можно предусмотреть событие относительного времени и переход по нему, то можно отлавливать истечение месяца и реакцию на это.
+ Протокольный автомат ломается, если что-то пошло не так. Поведенческий просто игнорит не предусмотренные события и продолжает жить припеваючи.

94

Sparx / Re: Как правильно использовать State/Continuation???

« Последний ответ от [прилетело НЛО и...] 26 Января 2022, 17:58:15 »

О. Вот интересная тема, подходящая для раскопа.
Сначала отложим в сторону Continuation. Визуально они схожи со State invariant, но смыслы у них разные (привет авторам UML!). Continuation -- элемент управляющий, так как рассказывает, куда дальше может пойти трасса. State invariant -- элемент разметки, который позволяет проверить валидна ли трасса или нет (но управлять её ходом он не может).
На приклеенной диаграмме у нас State invariant-ы.
Изначальный вопрос, видимо, про фичи Sparx, т. е. сделали соответствующую кнопочку или пункт в менюшке.
В общем случае мы вряд ли сможем восстановить всю диаграмму состояний. Мы можем восстановить только ту часть, которая кроется трассами, смоделированными диаграммой (диаграммами) последовательности. И для этого нам надо, чтобы на диаграмме в State invariant-ы были с именами состояний, а не такие как в примере: JDBC == BEGIN. Пример говорит нам лишь о том, что для того, чтобы трасса была валидна, в соответствующих точках должны быть выполнены условия. Мы можем догадываться, что условия из примера не совместны, но в общем случае Sparx-у это понять затруднительно. Без человеческой головы и рук тут не справиться.
Обратная задача -- построить диаграмму последовательности по имеющейся диаграмме состояний тоже достойна рассмотрения. Там тоже мы не достигнем полного восстановления требуемой диаграммы, но предположительно, полученные куски будут более осмыслены. Гипотетически, автомат много больше сообщает о возможных трассах, чем набор трасс -- об автомате.

95

UML SysML и пр. / Re: Шутки и UML

« Последний ответ от [прилетело НЛО и...] 19 Января 2022, 03:27:51 »

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

96

Примеры / Re: Use case диаграмма снятия денег в банкомате

« Последний ответ от [прилетело НЛО и...] 19 Января 2022, 00:01:17 »

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

97

Примеры / Re: Use case диаграмма снятия денег в банкомате

« Последний ответ от Galogen 12 Января 2022, 19:17:21 »

К слову во многих учебниках сделано также -- банк либо забыт и отрезан от банкомата, либо включён в рамки системы.

Что подтверждает факт, что диаграмма ВИ вообще не так уж и важна?

98

UML SysML и пр. / Re: "Плавательные дорожки" на диаграмме коммуникации

« Последний ответ от Galogen 12 Января 2022, 19:09:34 »

Это можно проделать только на листе бумажки или в рисовалке вроде Visio. Мы -- заложники производителей UMLьных инструментов. Как они сделают, так мы и сможем рисовать. Вот в VP решили, что плавательные дорожки на диаграммах коммуникации -- это гуд. И, не моргнув глазом, сделали их там. При этом VP заявляет, что поддерживает стандарт.

Да в VP затейники.

99

UML SysML и пр. / Re: Шутки и UML

« Последний ответ от Galogen 12 Января 2022, 19:08:32 »

Удачи всем в наступающем 2022-м!
Пусть сбываются Ваши планы!
Пусть будут успешны Ваши проекты!

Спасибо и Вам там на просторах Вселенной всего самого хорошего. А Вы кстати как определяете НГ, по обороту галактики вокруг ядра?

Шутка про крестики и нолики - классная:)

100

UML SysML и пр. / Re: Шутки и UML

« Последний ответ от [прилетело НЛО и...] 31 Декабря 2021, 15:09:49 »

Удачи всем в наступающем 2022-м!
Пусть сбываются Ваши планы!
Пусть будут успешны Ваши проекты!