136

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 17 Августа 2016, 13:30:35 »

В стандартной метамодели UML нет места, чтобы запомнить isDerived у класса.

Я тоже не нашёл. Но:

• В стандартной метамодели UML ассоциация имеет isDerived, а значит и некоторые классы (которые класс-ассоциации) могут быть производными
• В книге Рамбо и Блаха в 4.10. прямо сказано: "Производными могут быть классы, ассоциации и атрибуты" и пример есть (правда не очень хороший)

В книге есть попытка решить исходную проблему топика, но неудачная (рис.4.16.) - Vehicle может быть Car и Boat одновременно.

Можно без экзотики написать инвариант, запрещающий плохие комбинации наследования.

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

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

137

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 16 Августа 2016, 17:36:10 »

http://infocat.ucpel.tche.br/disc/mc/cmis.pdf глава "8 Derived Types".
Пункт "8.3.2 Derived by Specialization" на стр.170 содержит аналогичную ситуацию:
 context Square::allInstances():Set(Square)
 body: Rectangle.allInstances()->
 intersection(Rhombus.allInstances())

И в целом книга интересна, и другие произведения автора.

EnterpriseArchitect (не знаю с какой версии, но в 12 есть) даёт возможность в свойствах класса указать, что derived.

138

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 16 Августа 2016, 11:17:20 »

Лучший (по-моему) вариант.

139

Sparx / Re: Отобразить на диаграмме классов constraint атрибута

« : 01 Августа 2016, 09:11:34 »

Если делать ограничение как примечание, то можно соединить это примечание с определённым атрибутом: http://www.sparxsystems.com/enterprise_architect_user_guide/9.0/modeling_basics/connect_to_element_feature.html (это можно делать с любым типом связи!)

У меня в 9 версии не получилось (сделать можно, но на диаграмме ничего не меняется), а в 12 версии - получилось.

140

Sparx / Re: Отобразить на диаграмме классов constraint атрибута

« : 29 Июля 2016, 23:47:08 »

Вы должны все-таки понимать различия между моделью и графическим представлением.

Я понимаю, поверьте.

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

Моя позиция - графическое представление может и должно быть полным представлением модели (наглядным оно будет уже в силу того, что графическое). А текст служит не для представления модели, а для объяснений (в модели их нет и быть не может). Я понимаю, что я в меньшинстве, что практически во всех учебниках уважаемых (без кавычек!) авторов говорится: вот понятная, но неполная диаграмма, а вот полная модель. Но когда приходится сталкиваться с такой манерой документирования как читателю "большой и серьезной модели", первое что мне приходится делать - составлять собственную диаграмму, максимально полно отражающую модель! Я пробовал "читать" и по-другому, но не получалось (скачешь, скачешь между кучей страниц, а цельного представления нет).

141

Sparx / Re: Отобразить на диаграмме классов constraint атрибута

« : 29 Июля 2016, 23:20:32 »

Ни ухом ни рылом в EA. Обычный приём для отображения на диаграмме -- заведение примечания.

Можно и через примечание. Но примечание в EA можно присоединить к классу или ассоциации (к сожалению не к полюсу ассоциации), а для них и без примечания получается. А надо - к атрибуту, но нет возможности присоединить примечание к атрибуту (или я её не знаю). Выгода от присоединения - нет необходимости в ограничении определять контекст (ограничение получается немного короче).

142

Sparx / Re: Отобразить на диаграмме классов constraint атрибута

« : 29 Июля 2016, 20:46:54 »

Дело не в производном полюсе. Это вообще ограничение на конец ассоциации.

Если бы нашлось средство поместить на диаграмму не любое ограничение, а только правило вычисления производного элемента - это тоже подошло бы.

Для класса можно увидеть ограничения Class - Rules - Constraints - задаем разные ограничения, возможно и на значения атрибутов
Далее выделяем класс и Ctrl+Shift+Y (Feature and Compartment Visibility) - Show Element Compartments (или аналогично в свойствах диаграммы), но как показать именно для конкретного атрибута не получается

Спасибо, но интересовало именно для конкретного атрибута, тем более, что в модели есть поле Constraints и в аналогичной ситуации (для полюса) возможность есть.

143

Sparx / Отобразить на диаграмме классов constraint атрибута

« : 29 Июля 2016, 17:12:02 »

EA 9.0.908
Производный полюс ассоциации - заполняем Association Properties->Source/Target Role->Constraint(s) и видим на диаграмме, если Diagram->Properties..->Connectors->Show Connector Property String
Производный атрибут - заполнить вроде можно Attributes->Rules->Constraints, а как увидеть на диаграмме? Если есть решение для других версий - тоже подойдет.

144

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

« : 25 Июля 2016, 13:47:40 »

http://www.jot.fm/issues/issue_2007_10/paper2.pdf на странице 44 (10 с начала) там где Figure 4 есть про состояния истории.

145

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

« : 22 Июля 2016, 18:51:40 »

А идти "в само A" означает в начальное состояние A. Из него одна дорога - к историческому, а раз история пуста, то идём в само A...

146

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 22 Июля 2016, 16:43:07 »

Раз так, то просто провести явно неявные стрелочки на 1й диаграмме.

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

Авторы стандарта просто завели атрибут, чтобы хранить вид перехода. Почему бы не последовать их дурному примеру?)

Диаграмма, как её рисует стандарт (без constraint'ов) упрощается (правда появляется кратность 0..1 вместо 1..1 для атрибутов и ассоциаций), но модель в целом - усложняется (где-то constraint'ы надо указать).

Кстати про ABCDF. См. Figure 14.35.

Не уловил.

Ах, да. Про это писали выше.

Не уловил.

P. S. Рисунок гармонирует с ограничением state_is_external из 14.5.11.8.

Не уловил.

Как тут не вспомнить Джеймса Рамбо с его сакраментальным: "В ставке Гитлера все малахольные!"

Не уловил (откуда цитата знаю, наверное с чувством юмора проблемы).

147

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

« : 22 Июля 2016, 13:57:56 »

А если пуста?

148

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

« : 21 Июля 2016, 21:33:11 »

3-й случай интересен. Где-то, вроде, говорилось, что если нет предыстории и нет предыстории по умолчанию, то используется начальное [по умолчанию].

Если так, то нарисованный переход всё равно подразумевается, а значит всё равно требуется начальное псевдосостояние для A. И диаграмма во вложении не нарушает ничего, кроме здравого смысла! Понимаю, что приведенный пример против 3-го случая. 

Допустимость штука такая. Мы видим, стандарт не бьёт по рукам, значит, можно (или, значит, просто не бьёт?). Тянет отвечать вопросом на вопрос: А зачем? То есть, "позарез нужно, но допустимо ли" и "допустимо, но незачем" -- две разные ситуации.

Если "позарез нужно", то постараться, чтобы было "допустимо", а если "незачем", то безразлично "допустимо" или нет, лишь бы синтаксис и семантика были попроще. А бьёт ли стандарт - самый несущественный фактор.

149

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 21 Июля 2016, 18:22:26 »

A родитель перекрывающихся B и C, В родитель не перекрывающихся D и E, С родитель не перекрывающихся E и F.

Допустимыми должны быть только конфигурации: (ABD), (ABCE), (ACF). А так получается, что допустимой является и конфигурация ABCDF.

Если принять во внимание надписи, то можно подумать над набором классов -- все ли нужны.

Все нужны - на диаграмме этого нет, но каждый имеет особенность: или атрибут, или участие в ассоциации, или ограничение, или ещё что-нибудь.

150

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

« : 21 Июля 2016, 10:05:24 »

Ситуация - вопрос по допустимости