Коллеги, почему я могу использовать только один instance одного элемента на одной диаграмме??? Это дико раздражает (либо я чего то не понимаю)!

Давайте рассуждать здраво.  Актер, юзкейцс или другой элемент на модели, должен быть уникальным. Причем уникальность достигается не наименованием класса. а его идентификатором. Хотя имя класса в пакете должно быть уникальным. Тут я ругаю ЕА за то, что он позволяет создавать классификатор с одинаковым именем многократно в одном пакете.

Когда вы делаете ссылку, вы по сути включаете в пакет диаграммы ссылку на классификатор, т.е. почти сам классификатор. Ясно, что классификатор не может быть на одной диаграмме дважды, так что тут все в порядке. Претензий нет. И Еа делает все корректно

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

Правда мне сложно понять в чем проблема и почему так захотелось включить еще один инстансиси на одну и туже диаграмму?

Давайте рассуждать здраво.  Актер, юзкейцс или другой элемент на модели, должен быть уникальным. Причем уникальность достигается не наименованием класса. а его идентификатором. Хотя имя класса в пакете должно быть уникальным. Тут я ругаю ЕА за то, что он позволяет создавать классификатор с одинаковым именем многократно в одном пакете.

Когда вы делаете ссылку, вы по сути включаете в пакет диаграммы ссылку на классификатор, т.е. почти сам классификатор. Ясно, что классификатор не может быть на одной диаграмме дважды, так что тут все в порядке. Претензий нет. И Еа делает все корректно

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

Правда мне сложно понять в чем проблема и почему так захотелось включить еще один инстансиси на одну и туже диаграмму?

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

И все-таки я не понимаю, почему отображение одного классификатора на одной диаграмме не может быть дважды и более? Про ваше выражение "Актер, юзкейцс или другой элемент на модели, должен быть уникальным" - согласен абсолютно, только эта уникальность должна достигаться уровнем браузера проекта, а на диаграмме для удобства представления пользователю должна быть дана возможность отображения классификатора или его объекта произвольное количество раз, что мы и наблюдаем в таком продукте, как rational rose.

Про использование объектов классификаторов - то есть на каждое отображение актера делать новый объект от классификатора?

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

Прекрасный момент спросить, а правильно ли сделали диаграмму в таком случае? Если у вас возникла подобная проблема и вы не можете ее решить визуальными средствами как вам хочется, может посмотреть на ситуацию с другой стороны?
Нужна ли тогда подобная диаграмма?
Лично для меня обильное количество повторяющихся акторов только бы отвлекало от сути. Поймите. Диаграмма юзкейсов не имеет никакого практического значения, кроме как некоего оглавления, перечисления набора функций.
При этом все акторы по сути в дальнейшем нам не будут нужны вовсе, они за кадром, они те для кого мы делаем систему.
Если Вам нужно изобразить то, что Вы хотите используйте объекты, инстансисы. Это же просто изобразительное искусство и никакого значения на разрабатываемый продукт не имеет.
Так стоит ли копия ломать?
Причем а какие сложности показать 15 юзкейсов и двух актеров??
посередки юзкейсы - побокам два актера, линии хорошо ломаются и выстраиваются очень красиво и аккуратно веером

И все-таки я не понимаю, почему отображение одного классификатора на одной диаграмме не может быть дважды и более? Про ваше выражение "Актер, юзкейцс или другой элемент на модели, должен быть уникальным" - согласен абсолютно, только эта уникальность должна достигаться уровнем браузера проекта, а на диаграмме для удобства представления пользователю должна быть дана возможность отображения классификатора или его объекта произвольное количество раз, что мы и наблюдаем в таком продукте, как rational rose.

Так и пользуйтесь на здоровье розой, кто запрещает?
на мой же взгляд все абсолютно логично . Возможно со временем (хотя уже 7 версия чего было ждать) ЕА сделает вам такую фичу. Мне она ни разу почему-то не понадобилась. Если у вас такая трудность сделайте две разные диаграммы в разных пакетах, надеюсь будет вам

Про использование объектов классификаторов - то есть на каждое отображение актера делать новый объект от классификатора?

Ну именно это я и сказал по-моему?

Эд, реально нужно использовать два экземпляра одного и того же элемента на Д. Наример, рисуем Д БП, одно действие или составное действие используется несколько раз на Д с входами и выходами на разные Действия, получается нам нужно создать несколько элементов вместо того чтобы использовать все время один и тот же элемент и изменять его свойства в одном месте.

Эд, реально нужно использовать два экземпляра одного и того же элемента на Д. Наример, рисуем Д БП, одно действие или составное действие используется несколько раз на Д с входами и выходами на разные Действия, получается нам нужно создать несколько элементов вместо того чтобы использовать все время один и тот же элемент и изменять его свойства в одном месте.

Тут либо наше непонимание концепции UML, либо явное ограничение ЕА по своей внутренней модели.
Мне кажется нужно внимательно понять что ты хочешь от диаграммы и почему как ты хочешь сделать может быть неправильным. Пока мне сложно ответить так как нет картинки

Эд, реально нужно использовать два экземпляра одного и того же элемента на Д. Наример, рисуем Д БП, одно действие или составное действие используется несколько раз на Д с входами и выходами на разные Действия, получается нам нужно создать несколько элементов вместо того чтобы использовать все время один и тот же элемент и изменять его свойства в одном месте.

Согласен, была у меня такая же практика и такие же проблемы и ощущения.

На самом деле примеров тут можно привести множество, например, рисуем диаграмму Activity с целью отображения этапов исполнения бизнес-процесса с параллельным отображением сущностей на каждую деятельность. Юзаем элемент partition 2 раза, в первом будут сущности, во втором элементы деятельности. Сущности образуем как элементы типа object от соответствующих классификаторов, которые у нас определены на другой диаграмме, при этом на каждый классификатор есть 2 или 3 определенных состояния, которые нам надо перенести на сущности.
В данном случае становится вообще невозможным отобразить ситуацию, когда на одной диаграмме находится один элемент object с разными состояниями, которые определены для его класса! Я считаю, что это маразм (либо я чего то не понимаю...)

(либо я чего то не понимаю...)

Вот ключевая фраза

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

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

Рисуем класс, под ним рисуем его стейтмашину. Потом, там, где нам нужен экземпляр класса в определенном состоянии, рисуем объект этого класса, ПКМ, Advanced-Set Object State, в комбобоксе выбираем нужное состояние. И вот таких объектов в таких состояниях на диаграмме может быть столько, сколько нужно. Это решает проблемУ?

Вот ключевая фраза

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

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

Конкретный пример. Есть у нас класс-сущность "Заявление на отпуск". Есть у нас 2 определенных состояния для этой сущности - "пустой бланк" и "утверждено". Есть диаграмма деятельности, в которой я хочу показать, скажем, этапы жизненного цикла данной сущности. В диаграмме этой я использую конкретный неименной объект, классификатором которого является "Заявление на отпуск". Так почему я не могу ОДИН и ТОТ же объект показать 2 раза на диаграмме, при этом в первом случае он будет находиться в состоянии "пустой бланк",а в другом "утверждено"? Как я понимаю, объект ассоциируется именно с конкретным экземпляром (читай бумажкой) заявления, и именно этот экземпляр может иметь состояния как пустого бланка, так и потом ОН ЖЕ (ОН ЖЕ, то есть это не будет другой объект) будут подписан.

P.S. Хотел спросить вас - согласны ли вы с тем, что один объект может быть только в одном состоянии его классификатора? Спрашиваю, так как пытаюсь понять схему вашего мышления...

Рисуем класс, под ним рисуем его стейтмашину. Потом, там, где нам нужен экземпляр класса в определенном состоянии, рисуем объект этого класса, ПКМ, Advanced-Set Object State, в комбобоксе выбираем нужное состояние. И вот таких объектов в таких состояниях на диаграмме может быть столько, сколько нужно. Это решает проблемУ?

Именно так я и делаю, с точностью до каждой вашей фразы. Только вот "объектов в таких состояниях на диаграмме может быть столько, сколько нужно" есть не правда, объект такой может быть только один (точнее, их может быть сколько угодно, но при этом в браузере проекта будет соответствующая совокупность одноименных объектов). Сейчас еще раз попробовал.

что такое "клинируете..."?

Опечатка - клонируете

Есть диаграмма деятельности, в которой я хочу показать, скажем, этапы жизненного цикла данной сущности.

Не совсем хорошо, или совсем не хорошо. Хотя между диаграммой деятельностью и состояний много общего, все-таки это не полная аналогия. Потому все-таки для демонстрации ЖЦ лучше показывать это на диаграмме состояний

В диаграмме этой я использую конкретный неименной объект, классификатором которого является "Заявление на отпуск". Так почему я не могу ОДИН и ТОТ же объект показать 2 раза на диаграмме, при этом в первом случае он будет находиться в состоянии "пустой бланк",а в другом "утверждено"? Как я понимаю, объект ассоциируется именно с конкретным экземпляром (читай бумажкой) заявления, и именно этот экземпляр может иметь состояния как пустого бланка, так и потом ОН ЖЕ (ОН ЖЕ, то есть это не будет другой объект) будут подписан.

Именно так, только здесь у вас некоторый провал логики.
На самом деле вы изучаете (демонстрирует) не конкретное Заявление на отпуск, а вообще Заявление на отпуск.
Диаграмма деятельности - это ОО блок-схема в первую очередь, которая поток деятельностей и действий. На ней можно продемонстрировать и объектный поток, как в вашем случае. Однако сущность-объект -  это не совсем единичный объект, а некоторое совокупное понятие для всех Заявлений на отпуск. Такой объект - есть буфер (накопитель, хранилище, очередь, стек и т.п., который показывает накапливание однотипных объектов в одинаковом состоянии.

Т.е. Заявление на отпуск [Предложено] - Зарегистрировать - Заявление на отпуск [зарегено] - Рассмотреть и подписать - Заявление на отпуск [Подписано].

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

P.S. Хотел спросить вас - согласны ли вы с тем, что один объект может быть только в одном состоянии его классификатора? Спрашиваю, так как пытаюсь понять схему вашего мышления...

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

Мой ход мыслей следующий.

Класс в пределах пакета - уникальная сущность (хотя ЕА позволяет создавать сколько угодна классов с одинаковыми именами, что мне не нравится), т.е. по классике класс с именем А в пакете один.
В другом пакете может быть класс с тем же именем.
В любом случае в пределах некой системы класс- уникален - это полный аналог файла в файловой системе.
Имя класса - это не только его имя, но и имя всех пакетов в которые он входит иерархически

Аналогия с файлами и файловой системы бесподобна

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

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

Мое мышление говорит мне ЕА - это инструмент проектировщика, а не художника. Но даже для художника, два разных квадратика хотя бы и с одинковыми именами - это два РАЗНЫХ квадратика.

Я все сказал

Не совсем хорошо, или совсем не хорошо. Хотя между диаграммой деятельностью и состояний много общего, все-таки это не полная аналогия. Потому все-таки для демонстрации ЖЦ лучше показывать это на диаграмме состояний

Есть вопрос. А если я хочу показать те действия, которые переводят объект-сущность из одного состояния в другое? Пример, который вы приводите ниже с состояниями, с ним также я не согласен. Состояния "Зарегистрировать" и "Рассмотреть и подписать" не корректно именуются, "На регистрации" и "На рассмотрении и подписании" тогда уж. "Зарегистрировать" и "Рассмотреть и подписать" действия.

Однако сущность-объект -  это не совсем единичный объект, а некоторое совокупное понятие для всех Заявлений на отпуск. Такой объект - есть буфер (накопитель, хранилище, очередь, стек и т.п., который показывает накапливание однотипных объектов в одинаковом состоянии.

Хм, у меня другое представление об объекте. Обратимся, в качестве одного из примеров, к описанию объекта в самом хелпе EA:
"An Object is a particular instance of a Class at run time. For example a car with the license plate AAA-001 is an instance of the general class of cars with a license plate number attribute."
Под объектом я понимаю конкретный образец класса (конкретную машину с номером AAA-001), а не некоторое совокупное понятие для всех объектов классификатора (именно так я прочитал вашу мысль). На мой взгляд объект есть конкретный единичный объект классификатора.

Забавно то, что EA я использую для бизнес-моделирования и начальной постановки задачи. Перешел на EA с Rational Rose, пытаюсь применить те методы, которые использовал с успехом там (и которые собирал по крупицам из инета и прочих статей и книг).

Но даже для художника, два разных квадратика хотя бы и с одинковыми именами - это два РАЗНЫХ квадратика.

Почему же в Rational Rose это одинаковые квадратики?

Есть вопрос. А если я хочу показать те действия, которые переводят объект-сущность из одного состояния в другое? Пример, который вы приводите ниже с состояниями, с ним также я не согласен. Состояния "Зарегистрировать" и "Рассмотреть и подписать" не корректно именуются, "На регистрации" и "На рассмотрении и подписании" тогда уж. "Зарегистрировать" и "Рассмотреть и подписать" действия.

То что я привел - лишь пример, не имеющий к реальности никакого отношения. Чего его обсуждать?
Кроме того - это не состояния "Зарегистрировать" и "Рассмотреть и подписать", а деятельности или действия. Понимаете разницу?

Хм, у меня другое представление об объекте. Обратимся, в качестве одного из примеров, к описанию объекта в самом хелпе EA:
"An Object is a particular instance of a Class at run time. For example a car with the license plate AAA-001 is an instance of the general class of cars with a license plate number attribute."
Под объектом я понимаю конкретный образец класса (конкретную машину с номером AAA-001), а не некоторое совокупное понятие для всех объектов классификатора (именно так я прочитал вашу мысль). На мой взгляд объект есть конкретный единичный объект классификатора.

Да и ради бога, и флаг вам в руки.
Мы с вами о чем говорим? О применении объектов на диаграмме деятельности. Мы не обсуждаем диаграмму объектов.
Диаграмма объектов имеет занчимость для анализа и уточнения структуры диаграммы классов.

А вот когда мы говорим об объектах и объектных потоках на ДД, то объект там имеет несколько иной смысл. Который я вам пытаюсь передать - смотрите книгу Арлоу и Нейштадта UML2 и унифиуированный подход.

Забавно то, что EA я использую для бизнес-моделирования и начальной постановки задачи. Перешел на EA с Rational Rose, пытаюсь применить те методы, которые использовал с успехом там (и которые собирал по крупицам из инета и прочих статей и книг).
Почему же в Rational Rose это одинаковые квадратики?

Так пользуйетсь в этом случае привычным инструментом. Это раз
Обращайтеся к производителю ЕА - это два.

Я попытался передать свое понимание. ЕА конечно имеет минусы, а кто их не имеет.

Кроме того - это не состояния "Зарегистрировать" и "Рассмотреть и подписать", а деятельности или действия. Понимаете разницу?

Так я вам об этом и написал, а вы спрашиваете у меня же теперь "понимаете разницу".  ???
Ладно, дальше обсуждать этот вопрос смысла не имеет, уже в сторону пошли. Эдуард - за диалог тебе спасибо.

P.S. Из моего опыта - я знаю достаточно большое кол-во людей, которые юзают UML для решения тех или иных задач. Я смотрел диаграммы, которые они пишут. Для меня самое забавное то, что каждая группа использует его по своему (вплоть до своего понимания назначения той или иной диаграммы и элемента), некоторые почти до уровня Visio, просто порисовать.

Вот попробовал поработать в Visual Paradigm.


Сделал
1. диаграмму активности
2. диаграмму юзкейсов
3. диаграмму классов

Предположим есть диаграмма юзкейсов. Из Model Explorera кидаю на диаграмму класс 1, раз, два три - кидается, ничего не говорит. Зер гуд. То что вы веротяно ждете. Далее. Рисую связи от класс 1 к классу 1 и еще к классу 1

Делаю диграмму классов, переношу, кидаю туда класс 1. Сразу образуются self-ассоциации ровно три штуки. Замечательно

Беру диаграмму активности: создаю пару активностей, кидаю класс 1 раза 4. Создаются ровно 4 объекта.

Внимательно смотрю на элеенты модели и что вижу? Объекта как такового нет - это Object Node причем двух разных типов Central Bufeer Node и Data Store Node

Те объекты что я создавал из класс 1 на самом деле теже самые Object Node. У них даже есть тип сортировки накапливаемых объектов.
Далее беру создаю еще один Object Node. Мышкой вытаскиваю его с Model Explorer раз 5. Задаю одному из них состояние.
Все другие клоны имеют тоже самое состояние