1

UML SysML и пр. / Re: Ассоциация внутри класса

« : 27 Июня 2022, 11:02:39 »

По ссылке https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-composite-structure-diagram/ смотрел "Deriving Composite Structure Diagram from Class Diagram" и так и не понял, что предлагается:
   1. использовать диаграмму составной структуры вместо диаграммы классов
   2. использовать диаграмму составной структуры вместе с диаграммой классов
И в одном, и в другом варианте вижу проблемные места:
   если 1., то не всё выражено
   если 2., то есть нестыковки

2

Для всех / Re: Поиск удобной нотации для отображения зависимостей объектов

« : 15 Июня 2022, 10:10:41 »

OCL вроде не поддерживает навигацию по тернарным ассоциациям.

3

Для всех / Re: Поиск удобной нотации для отображения зависимостей объектов

« : 14 Июня 2022, 16:21:51 »

На диаграмме классов для тернарной ассоциации Matches надо как-то обозначить, что объектов-плейсходлеров в экземпляре тернарной ассоциации должно быть не более одного.

4

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

« : 03 Февраля 2022, 15:54:16 »

Мы смотрим на 14-33 немашинным взглядом. Если делать модель в расчёте на скармливание какой-нибудь софтине, то и не такое рисуется (иногда даже не рисуется, так как модель не содержит диаграмм, являясь лишь деревцем в проводнике.

Если смотреть "машинным" взглядом, то ситуация становится ещё "жэстачайшэ" - машине надо объяснить, где информационное свойство является избыточным (может/должно быть выведено - derived), а где только ограничение (constraint).
Я расцениваю 14-33 как желание отобразить:
1. 2 класса связаны ассоциацией
2. оба класса имеют одинаковый набор подклассов
3. ассоциироваться могут только одноименные подклассы
4. мощность "подчиненных" ассоциаций - такая же, как у "обобщающей" ассоциации
Пусть хотя бы с одной стороны мощность ассоциации такова, что становится обязательной (1..1 или 1..*). Тогда, например если model имеет мощность 1..1 или 1..*, то разбиение Symbol на OrderSymbol и CustomerSymbol становится выводимым из разбиения Subject на Order и Customer.
Если же с обеих сторон мощность необязательна (0..1 или 0..*), то имеем дело с ограничением.

5

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

« : 03 Февраля 2022, 15:14:04 »

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

Не могу попробовать VP. Но в MagicDraw работает так:
1.   Тернарная (и выше) ассоциация имеет отдельный знак – «ромбик».
2.   Чтобы нарисовать «хвосты» используются бинарные ассоциации между «ромбиком» и классами.
3.   Эти бинарные ассоциации и другие «обычные» бинарные ассоциации являются объектами для соединения с помощью обобщения. Можно даже сделать, что один «хвост» обобщает другой. Единственное ограничение – обобщения не могут зацикливаться.
4.   Нельзя делать обобщения между «ромбиками».
Подозреваю, что VP работает так же.

6

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

« : 02 Февраля 2022, 14:20:52 »

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

Спасибо, книга "Пионеры программирования" вроде есть, перечитаю.

14-33 мне тоже нравится, в частности, тем, что мне неизвестна UML-среда (а не графическая рисовалка), позволяющая это нарисовать. В реальной среде возможны либо redefines-ы на полюсах, либо подвески классов ассоциаций и обобщения между ними.

1. Мне 14-33 НЕ нравится для указанной ситуации - Период связан ровно с одним ТипПериода, который имеет подтипы, значит Период тоже имеет тот же набор подтипов, причем специализация по этим подтипам является вычислимой. Это не должно требовать такого "громоздского" представления на диаграмме, как 14-33.
2. В MagicDraw 16.6 мне удалось сделать обобщение между ассоциациями.

7

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

« : 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..*, всегда что-то "не то".

8

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

« : 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>>). Например, в примере дубли одного и того же периода, входящие в состав разных контейнеров должны быть различными экземплярами или одним и тем же экземпляром?

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

9

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

« : 19 Августа 2021, 16:38:35 »

Как только появляется

- иерархическая система категорий

то

- способ связывания объектов с категориями

обрастает рядом дополнительных вопросов, например:
1. В связи могут участвовать только категории-листья?
2. В связи с одним объектом могут участвовать и категория-предок, и категория-потомок?
3. В связи с одним объектом могут участвовать категории с общей категорией-предком?
4. Как может изменяться сама "иерархическая система категорий":
- листья могут становиться не листьями?
- не листья могут становиться листьями?
- категории могут менять непосредственного предка?

10

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 28 Декабря 2020, 16:49:36 »

Ещё по материалам сайта:
статья "Blog"->"Relational Data Design"->"Part One - Methodology and Benefits", рисунки 15 и 16 (Relational Meta Model).
Не совсем точное описание foreign key:
1. поле может несколько раз входить в один и тот же foreign key (может так и надо?)
2. не каждому полю связанного primary key соответствует поле foreign key (а так точно быть не должно!)

11

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 28 Декабря 2020, 09:34:02 »

Сайт интересный, поднимаются важные темы, но и не без ошибок.
Заметки по Perspective и Tutorial Part One - во вложенном файле.

12

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 17 Декабря 2020, 10:18:20 »

Добурило до куриных/вороних лапок по рецепту Баркера. Отвал башки. Благодарю.

Удалось найти первоисточник - произведение самого Баркера (примерно 1989 года) или перевод на русский язык (видел примерно в 1993 году)?

13

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 15 Декабря 2020, 16:42:33 »

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

14

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 14 Декабря 2020, 13:55:38 »

Берём список Vadim'а, надеясь, что он не против

Не против, даже рад разбору - сам бы хотел, да не смог так внятно изложить особенности каждой книги!

2. Джим Арлоу и Айла Нейштадт "UML 2 и Унифицированный процесс", 2-е издание, 2008
Чуть ли не единственная с внятным сообщением про OCL, с адекватным UML 2.0 описанием диаграмм деятельности. При сравнительно большом количестве переведёнок по RUP Арлоу+Нейштадт -- диковинка с рассмотрением унифицированного процесса не в версии от Rational.

Про эту бы ещё добавил - "Чуть ли не единственная с внятным сообщением про" отношение extend.

15

ПО Аналитика / Re: MadicDraw 16.6, отражение на диаграмме классов уникальности атрибута

« : 20 Августа 2020, 12:55:14 »

Может неудачно сформулировал вопрос, но интересовало отображение на диаграмме свойства isID (в виде {id}).