Не логично. Это не отношение наследования. Это отношение вложения. Т.е. класс определен в рамках другого класса. заблы как точно это называется, кажется вложенные классы или вложенное определение класса. Именно это и отражает ЕА, поскольку механизмы работы в нем едины для многих UML элементов

А почему вложение не показывать через агрегацию композицию?

Кстати почему то EA реализовал эту вложенность не через линки (t_connector)  а через прямую ссылку обьекта на обьект (t_object)

А почему вложение не показывать через агрегацию композицию?

У меня тоже была такая мысль, почему это ЕА не сделал так, чтобы автоматом появлясь связь агрегации. НО вложенный класс - это не часть агрегата, это часть самого главного класса. В этом то и тонкость... наверное

ГЫыыы честно говоря слишком тонкая тонкость...

ГЫыыы честно говоря слишком тонкая тонкость...

А зря, хахалитесь . Я сказал, разница есть. И по-моему она серьезна. Другое дело лично я ее до конца не понимаю, вернее выразить не могу. Потому обратился к ЕА за помощью. Есть там очень интересный инструмент - =иерархия= -.
Сразу так в чувство приводит

Создадим класс Class1. Сделаем его большим-пребольшим. Поместим на него еще один класс Class2. Еще сделаем рядышком Class3. Свяжем Class3 агрегацией с Class1. Потом взглянем на иерахию. Например от Class1:
владеет Class2 и !!!! состоит из Class3. Есть разница - владеть и состоять? Но пойдем дальше. Добавим Class4 и свяжем его композицией. Ну и? А никакой разницы... Разница уже такова - что часть не существует вне целого.

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

В вот наш класс 2 - определяется исключительно внутри класса 1. Без класса 1 он не существует и имеет значение только внутри этого самого класса 1. Какова практическая значимость такой ситуации- мне сказать сложно, надеюсь более опытные товарищи подскажут

ну есть отношение nested

кстати одна из засад такого странного отношения к линкам -
1 берем пакет
2 сохраняем на диск (XMI)
3 добавляем связь между элементами пакета
4 сравниваем пакет с ранее сохраненным на диске XMI
5 EA говорит что они идентичны

Во как

свойства ParentID в дочернем элементе задается родитель. Но родитель именно в смысле project browser. Каково отражение отношения родитель-ребенок (project browser) в UML отношения

Я тоже задавался этим вопросом.
В смысле соответствия UML-ному стандарту,
я вижу интерпретацию связи родитель-ребенок в project browser EA только в контексте пакетов.

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

Так вот, интересно, что в ЭА роль пакета может исполнять и класс,  и состояние, и активность, и Юзкейс похоже, любой элемент модели, изображение которого на диаграмме имеет вид фигуры с полощадью.
Как минимум, в контексте project browser-а.

Как-то мне по работе нужно было дать Заказчику диаграмму зависимости пространств имён в разрабатываемом .NET-приложении.
Получилось достаточно удачная диаграмма файлов-компонентов, в которых содержались пакеты-пространстваИмён. (Я использовал MagicDrowUML)
Мне очень понравилась конструкция с плавным переходом:
NameSpace.SubNameSpace.ClassName.ClassFunctionName()

Если NameSpace и SubNameSpace моделируем на диаграммах пакетами, то логично пойти дальше, и воспринимать и ClassName и ClassFunctionName тоже как в каком-то смысле, пакеты.

Например, диаграмму состояний (вместе с состояниями) можно сделать в project browser-е дочерней для соответствующего класса.

Диаграмму активности, детализирующую ЮзКейс, вместе с активностями - делаем дочерними самому Юзкейсу.


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

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

Но не всё так красиво в ЭА.
Мы с Galogen-ом давно нарвались на обидный хомут:
Есть функция у класса, очень хочется активити-диаграмму с алгоритмом вычисления этой функции сделать дочерней...
Ан-нет :-( ЭА функцию в дереве показывает, а прицепить к ней дочерний элемент не даёт.

Ещё - ЭА не хочет цеплять пакет дочерним куда бы то ни было, кроме другого пакета.

Но самое страшное - это риск "полного съезда крыши" у ЭА,
как только начинаешь более-менее основательно перестраивать дерево браузера.

Как делается направление чтения имени ассоциации?

Как делается направление чтения имени ассоциации?

Александр, к сожалению в ЕА нет явных средств для этого, как, например, в VISIO. Однако следует придерживаться правила справа-налево-сверху-вниз.

Я выкручивался путем изображения направления навигации или включения в текст имени ассоциации знака -> или <-. Конечно не так удобно. Однако направление чтения часто тривиально и понимаемо

Я выкручивался путем изображения направления навигации или включения в текст имени ассоциации знака -> или <-. Конечно не так удобно. Однако направление чтения часто тривиально и понимаемо

Прийдется выкручиваться...

Всем доброго вечера .

Собственно вопрос: как заставить EA показывать на диаграмме классов параметры методов в соответствии с нотацией UML?

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

У них на форуме уже спрашивал - стандартными средствами никак.

Может быть это можно сделать с помощью add-ins-а или еще как-то?

Всем доброго вечера .
Собственно вопрос: как заставить EA показывать на диаграмме классов параметры методов в соответствии с нотацией UML?
Очень хотелось бы чтобы для методов он показывал значения параметров по умолчанию, сейчас максимум что можно это название и тип.
У них на форуме уже спрашивал - стандартными средствами никак.
Может быть это можно сделать с помощью add-ins-а или еще как-то?

Вечер добрый.

Как Вы сами и сказали, на форуме Вам ответили - нет нельзя.
Однако вопрос: что такое "отобразить параметры методов в соответствии с UML". Т.е. если дефолтные значение не отображаются, то это уже будет не в соответствии?

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

Я согласен с Вами ЕА в очередной раз прокололся.

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

В Visual Paradigm полную сигнатуру операции или метода можно изобразить без лишних хлопот. Существует бесплатная версия Community Edition.

Однако вопрос: что такое "отобразить параметры методов в соответствии с UML". Т.е. если дефолтные значение не отображаются, то это уже будет не в соответствии?

В полном соответствии со спецификацей UML (это, естественно, только кусок):

Код: [Выделить]

<parameter-list> is a list of parameters of the operation in the following format:
   <parameter-list> ::= <parameter> [‘,’<parameter>]*
   <parameter> ::= [<direction>] <parameter-name> ‘:’ <type-expression>
  [‘[‘<multiplicity>’]’] [‘=’ <default>] [‘{‘ <parm-property> [‘,’ <parm-property>]* ‘}’]

Т.е. если я ставлю для диаграммы "Show Parameter Detail" в "Full Details" - то по-моему должно показываться все что определено нотацией, а не только название и тип.

Насколько я понимаю UML все-таки графическая система, значения по умолчанию скорее уже ближе к реализации.

Однако для атрибутов с этим проблем нет - дефолтные значения показываются.

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

Проблема в том, что у меня есть классы (на PHP5) у которых методы допускают вызов с различным числом параметров (1, 2, 3 и тд), НО по диаграмме невозможно определить сколько параметром можно передавать методу - приходится постоянно лезть в свойства...

Да в VP это все показывается, но по-моему он слишком навороченный, ну и стоит естественно больше. Community Edition не подходит т.к. там нет генерации кода , а без неё вообще мало смысла использовать UML... если все делать вручную - проще рисовать в Visio или ConceptDraw.

И всетаки - может существует какой-либо обходной путь, чтобы заставить EA показать дефолтные значения?