81

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

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

Изначально цитата, понятно, взята из "В бой идут одни старики". Произносит её механик Макарыч (Алексей Смирнов). Что-то близкое по смыслу Рамбо сказал Бьянкуцци и Уордену, а они записали в своей книге "Пионеры программирования" https://vk.com/wall-54530371_793 в главе об UML. Двое других из "троих друзей" были настроены не так воинственно.
14-33 мне тоже нравится, в частности, тем, что мне неизвестна UML-среда (а не графическая рисовалка), позволяющая это нарисовать. В реальной среде возможны либо redefines-ы на полюсах, либо подвески классов ассоциаций и обобщения между ними.
Допущения в первоначально составленной модели прояснились. Не думаю, что хоть чего-то стоят мои уточнения к ней. Было приятно потрындеть, спасибо.

82

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

« Последний ответ от Vadim 02 Февраля 2022, 11:33:57 »

С тех пор прошло много времени и Рамбо сказал своё знаменитое "В ставке Гитлера (т. е. в IBM) все сумасшедшие", давая интервью о том, почему UML3 не будет.

Можно ссылочку и цитату?

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

Возможные варианты отражения ситуации на диаграмме при строгом следовании стандарту:
   1. цитата: То есть класс Период должен лежать снаружи, а его имя должно использоваться как тип у роли/части.
   2. что-то похожее на рис.14-33 из того же источника 

2 оконечные точки или одна зависит от того верим ли мы в LSP, строя модель. Почему-то кажется, что традиционный способ за-redefine-ть периоды, входящие в состав "без промежутков", указав, что у них точка становится выводимой.

В Liskov substitution principle мы верим всегда. Не выходя за рамки этой веры можно:
   1. Не указывать производные (derived) элементы вообще - как и сделано
   2. Указать, что Период имеет атрибут "Конец:Дата", который для Периода типа "Без промежутков" является производным (ну тогда уж и как вычисляется)
В реальной жизни я бы скорее использовал 2., но для обозначения ситуации 1. попроще.

Попутно замечу траблы (14-31) одного из трёх друзей относительно мощностей при полюсах тернарной ассоциации. Быть может, опечатались.

Для меня мощности при полюсах n-арной ассоциации, отличные от 0..* и 1..*, всегда что-то "не то".

83

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

« Последний ответ от [прилетело НЛО и...] 01 Февраля 2022, 23:55:02 »

С тех пор прошло много времени и Рамбо сказал своё знаменитое "В ставке Гитлера (т. е. в IBM) все сумасшедшие", давая интервью о том, почему UML3 не будет.
В нынешнем стандарте истребили следы того, что рамка пакета или компонента и рамка класса или кооперации вели себя схожим образом. Внутри рамки класса не может быть другого класса или типа. Внутри компонента может.
2 оконечные точки или одна зависит от того верим ли мы в LSP, строя модель. Почему-то кажется, что традиционный способ за-redefine-ть периоды, входящие в состав "без промежутков", указав, что у них точка становится выводимой.
Попутно замечу траблы (14-31) одного из трёх друзей относительно мощностей при полюсах тернарной ассоциации. Быть может, опечатались.

84

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

« Последний ответ от Vadim 01 Февраля 2022, 14:49:00 »

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

Можно и как в стандарте - не класс, а роль, но:
   1. с указанием класса
   2. с именем роли как у полюса ассоциации
   3. с множественностью роли как у полюса ассоциации
А если посмотреть https://www.utdallas.edu/~chung/Fujitsu/UML_2.0/Rumbaugh--UML_2.0_Reference_CD.pdf рис.14-84, то ...

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

Контейнер, кроме объединения периодов, имеет собственные информационные свойства, например Наименование. 

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

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

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

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

85

Задачи студентов / Re: UseCase, описывающий процесс авторизации пользователя на сайте

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

Некротрединга псто.
Название ВИ должно отражать то, что в нём происходит. Кажется, что Ваши ВИ "Upload file" и "Download file" в переводе на русский не должны содержать в названии "Получить доступ", т. к. цель в обоих случаях другая (чтобы пачки данных переместились).
Само по себе получение доступа, после того как юзер залогинился, представляет собой один шаг системы ("чекнуть права учётной записи, от имени которой пришёл запрос".
Сценарий upload-а, как и сценарий download-а скорее всего имеет альтернативный поток, хотя бы один.
Постусловие не может быть дополнительным шагом, который доделывается после того, как выполнение ВИ завершилось. В самом сценарии должны быть шаги обеспечивающие истинность постусловия. Мы видим довольно сомнительное описание ВИ Download в котором шаг 3 описан примерно так: User осуществляет download. Это какая-то дурная рекурсия. Сам сценарий составлялся ради того, чтобы по шагам раздробить download, а не для того, чтобы констатировать, что этого сделать нельзя и что download есть download.

86

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

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

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

87

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().

88

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

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

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

89

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

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

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

90

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

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

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