31

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

« : 31 Января 2022, 15:39:02 »

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

32

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

33

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

« : 26 Января 2022, 18:31:26 »

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

34

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

« : 26 Января 2022, 17:58:15 »

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

35

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

« : 19 Января 2022, 03:27:51 »

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

36

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

« : 19 Января 2022, 00:01:17 »

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

37

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

« : 31 Декабря 2021, 15:09:49 »

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

38

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

« : 21 Ноября 2021, 17:44:17 »

Вы уже где-то попробовали?

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

39

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

« : 21 Ноября 2021, 17:04:31 »

Это все Thinkler, он отрезал.

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

40

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

« : 06 Октября 2021, 18:09:32 »

На сайте Visual Paradigm встретилась замечательная диаграмма:

См.: https://www.visual-paradigm.com/VPGallery/diagrams/Collaboration.html
Замечательна она тем, что авторами VP swimlane-ы, придуманные задолго до UML и взятые в UML почему-то только для диаграмм деятельности, органично вплетены в стандартную нотацию. Залезание в текст стандарта подтверждает ожидания. Это не стандартная нотация. Swimlane-ам место лишь на диаграммах деятельности.

Но что если копнуть глубже и посмотреть, что стандарт не запрещает рисовать на диаграммах коммуникации. И тут нас ждёт сюрприз. Вся диаграмма коммуникации по стандарту = дерево с корнем, являющимся Interaction. В привычной диаграмме коммуникации из Interaction растут ветви в сторону его детей -- Lifeline-ов всяческих, Message-ей. Это согласуется с абстрактным синтаксисом. Но этот синтаксис говорит, что дитём Interaction-а вполне может быть InteractionFragment, то есть, и CombinedFragment. Значит, что стандартом не запрещено рисовать непривычные диаграммы коммуникации -- с alt-, loop- или opt- фрагментами. Чего по привычке никто не делает.

Так что, меняем "плавательные дорожки" на комбинированные фрагменты и вперёд!

41

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

« : 18 Сентября 2021, 22:59:37 »

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

42

Теория моделирования и нотации / Re: UML диаграмма классификации (категоризации)

« : 20 Августа 2021, 13:08:39 »

обрастает рядом дополнительных вопросов, например:...

Предположительно, можно взять часть метамодели UML, относящуюся к структуре, кроющую классы и экземпляры. Далее отождествить Class с категорией, а InstanceSpecification с объектом. Получившаяся недометамодель UML даст требуемую якобы гибкость в плане неопределённости объектов, категорий и ответов на вопросы. Но манипулировать данными в такой системе будет неудобно.

Идея подсмотрена у Скотта Амблера. Это расширенная его generic schema, которую он описал для ORM.

43

Теория моделирования и нотации / Re: UML диаграмма классификации (категоризации)

« : 16 Августа 2021, 21:46:13 »

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

Если задачей является "чтобы на UML", то хотя бы себе Вы должны дать ответ. Зачем именно UML и зачем визуальная модель.

Библиотечная классификация специализирована. Ею пользуются библиотечные спецы. Обычные люди [вроде Вас] и марсиане [вроде меня] ею пользуются с грехом пополам. И там почти всё давно придумано, а специальные институты патчат и дополняют при необходимости. Книга издаётся с метаданными -- готовой пачкой сведений для классификации. Я давно видел библиотекарей, но и тогда они не производили впечатление людей, которые читают книги для выполнения своих библиотекарских обязанностей.

Бутерброды, в принципе, тоже бывают размечены. В самолётной классификации "курицалилирыба" на лоток с питанием может быть наклеен цветной ярлык.

Какие ярлыки на Ваших объектах-записях? Если известно лишь то, что "структура этих объектов-записей довольно простая" и больше  нечего сказать, то модель будет тривиальной (не содержательной), и набросать UML-диаграмму не будет никакой возможности (из-за отсутствия сведений). На контрпример, диаграмм про книги Вы на тутошнем форуме можете найти несколько штук.

У Борхеса есть такая классификация:
животные делятся на:
а) принадлежащих императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.

Даже на таком шатком основании можно что-то построить.

Но не на облаке.

44

Теория моделирования и нотации / Re: UML диаграмма классификации (категоризации)

« : 16 Августа 2021, 17:35:39 »

К теории моделирования и нотациям Ваш вопрос не имеет отношения, насколько я могу судить.
Если речь идёт о полученном Вами задании, то выполните его сами или обратитесь на фриланс-сайт.
Затруднительно понять из Вашего сообщения, что за задача перед Вами стоит, с какой целью Вы ею занимаетесь, при чём тут UML.

Библиотечная классификация -- специализированная вещь, отличающаяся от обобщённой классификации "объектов по каким-либо категориям". Так, на книге есть шифры -- ББК и всякие там ISBNы. Просто глядя на них Вы получаете ответ на вопрос: "содержится" ли книга в категории "Приключения". На книге есть значок ограничения по возрасту (если она издана после вступления в силу соответствующих законов). Глядя на них Вы узнаете, относится ли книга к категории "Детям до 12 лет". На книге есть дата выпуска тиража. По нему Вы получите ответ про "Период публикации".

Но если Ваша система категоризует/классифицирует бутерброды, то, просто взглянув на бутерброд, вряд ли можно определённо ответить:
относится ли он к категории "Приключения"?
предназначен ли он детям до 12 лет и годится ли для детей постарше?

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

45

UML SysML и пр. / Re: UML Best Practice: "На диаграммах деятельности не рисуйте деятельности"

« : 28 Июля 2021, 17:19:10 »

Но если у узла нету пина, то остается неопределенным, чему равен признак isSynchronous этого узла.


А вообще, есть какие-нибудь средства (нотации) моделирования, которые позволяют графически наглядно показать асинхронные вызовы?

Приплету, что по стандарту дефолтное значение isSynchronous = true. Из экономии мы можем полагать, что диаграмма без явных указаний чего-либо про isSynchronous означает, что значение дефолтное. Тогда неопределённое значение нашим усилием приравнивается к дефолтному.
Стандарт не содержит примеров явного указания isSynchronous. Поэтому кочку опоры придётся придумать самим. Например, известно, что класс, которому отказано в праве на переопределение в потомке метится isLeaf=true. Известно, что стандарт не даёт примера конкретного синтаксиса. Поэтому народ рисует так:

Вот и мы можем писать что-то вроде {asynchronous}.
Тут надо заметить, что тот же  isLeaf=true для State стандарт позволяет рисовать кейвордом {final} после называния состояния. Это чтобы с final state-ом перепутывать что ли?
В сторону можно заметить, что несчастный класс должен помимо  isLeaf ещё размечаться isFinalSpecialization. То есть почва зыбкая, даже авторы стандарта "плывут".

И надо запастись поп-корном и сесть ждать когда наконец будет нормальное описание не только абстрактного синтаксиса UML, но и конкретного синтаксиса тоже.