Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
kris, а может, для бизнес-моделирования использовать BPMN? Она ведь для этого и предназначена, в отличие от UML? ЕА поддерживает и эту нотацию.Все верно, этой нотацией я также пользуюсь. Только вот BPMN - низкоуровневая нотация бизнес-моделирования. А если мне требуется показать, скажем, организационную структуру или выделить перечень ролей, документов и т.д...
DВсе зависит от точки зрения. Мне все равно не очень понятна ваша потребность на одной диаграмме иметь несколько фантомов одно и того же класса. Мне как-то всегда удавалось обойтись одинСкажем так. Есть задача (например) сделать бизнес-моделирование с целью последующей оптимизации бизнеса или постановки задачи на разработку программного обеспечения. При этом все условия для начала работы присутствуют - обозначены и цели, задачи, границы моделирования. Вроде как есть способ графического представления - нотация UML и ее расширения. Но UML - набор диаграмм, и надо еще понять, как все это дело использовать для достижения требуемого результата.. Другое дело другие диаграммы, там можно повторять ссылки на классы. И получиться то, что вы говорите о изменении документации
Предположим есть диаграмма юзкейсов. Из Model Explorera кидаю на диаграмму класс 1, раз, два три - кидается, ничего не говорит. Зер гуд. То что вы веротяно ждете.Да, верно, это то, что мне нужно.
Не смотря на то, что в браузере проекта появляются новые классы, физически это есть одни класс. Кроме вашего способа проверки, можно просто для одного из классов вписать что-нибудь в документацию - она поменяется для всех отображений классов. В EA так сделать нельзя.Кроме того - это не состояния "Зарегистрировать" и "Рассмотреть и подписать", а деятельности или действия. Понимаете разницу?Так я вам об этом и написал, а вы спрашиваете у меня же теперь "понимаете разницу".
???
Не совсем хорошо, или совсем не хорошо. Хотя между диаграммой деятельностью и состояний много общего, все-таки это не полная аналогия. Потому все-таки для демонстрации ЖЦ лучше показывать это на диаграмме состоянийЕсть вопрос. А если я хочу показать те действия, которые переводят объект-сущность из одного состояния в другое? Пример, который вы приводите ниже с состояниями, с ним также я не согласен. Состояния "Зарегистрировать" и "Рассмотреть и подписать" не корректно именуются, "На регистрации" и "На рассмотрении и подписании" тогда уж. "Зарегистрировать" и "Рассмотреть и подписать" действия.
Однако сущность-объект - это не совсем единичный объект, а некоторое совокупное понятие для всех Заявлений на отпуск. Такой объект - есть буфер (накопитель, хранилище, очередь, стек и т.п., который показывает накапливание однотипных объектов в одинаковом состоянии.Хм, у меня другое представление об объекте. Обратимся, в качестве одного из примеров, к описанию объекта в самом хелпе EA:
Но даже для художника, два разных квадратика хотя бы и с одинковыми именами - это два РАЗНЫХ квадратика.Почему же в Rational Rose это одинаковые квадратики?
Рисуем класс, под ним рисуем его стейтмашину. Потом, там, где нам нужен экземпляр класса в определенном состоянии, рисуем объект этого класса, ПКМ, Advanced-Set Object State, в комбобоксе выбираем нужное состояние. И вот таких объектов в таких состояниях на диаграмме может быть столько, сколько нужно. Это решает проблемУ?Именно так я и делаю, с точностью до каждой вашей фразы. Только вот "объектов в таких состояниях на диаграмме может быть столько, сколько нужно" есть не правда, объект такой может быть только один (точнее, их может быть сколько угодно, но при этом в браузере проекта будет соответствующая совокупность одноименных объектов). Сейчас еще раз попробовал.
Вот ключевая фразаНет, и все таки я вас не совсем понимаю (точнее, не понимаю)...
Вот давайте рассуждать. Есть некий объект - экземпляр некоего класса, который меняет состояния.
Нам нужно отобразить три состояния этого объекта.
1. для этого есть диаграмма состояний
2. интересно как для одного и того же объекта (в смысле как некий фиксированный элемент графический) отобразить три разных состояния имея только один такой элемент на диаграмме. Да же если вы его клинируете ссылаясь на 1 объект, то почему вы считаете, что изменение состояния в одном месте не должно приводить в этом случае в другом?
Давайте конкретнее. Ваша фраза "три разных состояния имея только один такой элемент на диаграмме" - верно ли я понимаю, что под "диаграммой" вы подразумеваете именно диаграмму, а не project browser? Если да, то никак (отвечая на ваш вопрос), но я то имел ввиду совсем другое - когда в project browser у нас 1 объект, на диаграмме несколько его отображений, каждое из которых имеет свое состояние, наследуемое от состояний класса объекта. Далее вы написали "Да же если вы его клинируете..." - фразу не понял вообще, что такое "клинируете..."?Эд, реально нужно использовать два экземпляра одного и того же элемента на Д. Наример, рисуем Д БП, одно действие или составное действие используется несколько раз на Д с входами и выходами на разные Действия, получается нам нужно создать несколько элементов вместо того чтобы использовать все время один и тот же элемент и изменять его свойства в одном месте.Согласен, была у меня такая же практика и такие же проблемы и ощущения.
Давайте рассуждать здраво. Актер, юзкейцс или другой элемент на модели, должен быть уникальным. Причем уникальность достигается не наименованием класса. а его идентификатором. Хотя имя класса в пакете должно быть уникальным. Тут я ругаю ЕА за то, что он позволяет создавать классификатор с одинаковым именем многократно в одном пакете.Основная идея включения - чтобы графически диаграмма выглядела понятно. При наличии 2 актеров и, скажем, 15 кейсов на них получается большое кол-во длинных связей. При наличии бы возможности множить отображение актера каждый актер находится рядом со своим кейсом - понять легко, что к чему.
Когда вы делаете ссылку, вы по сути включаете в пакет диаграммы ссылку на классификатор, т.е. почти сам классификатор. Ясно, что классификатор не может быть на одной диаграмме дважды, так что тут все в порядке. Претензий нет. И Еа делает все корректно
Для того, что Вам нужно - следует использовать объекты классификатора.
Правда мне сложно понять в чем проблема и почему так захотелось включить еще один инстансиси на одну и туже диаграмму?
ой там моделище, а не моделька, думаю вряд ли у почтенного общества хватит желания усе там проверять и пониматьДа нет. Все еще впереди. Над ней работать и работать мне еще.
galiaskarov злой собака isuct офигенная точка ruКакой злой адрес:). Ушло.
Дык нет в свободном доступе перевода RUP на русский язык.Ну, на одном сайте видел я на русском очень краткое описание самой сути бизнес моделирования по RUP.
UML и Rational Rose по-моему сильно разные вещи, одно нотация моделирования, другое продукт, это как теплое и мягкое.Железно, с этим трудно не согласиться. В целом, направление Ваших мыслей мне вполне понятно, хотя и не могу сказать, что полностью с ними согласен.
. В All Fusion Process Modeler думать тоже часто приходится... Идея в том, что если каждый бизнес аналитик, работая с UML, будеть так вот "думать", то смогут ли они правильно понять сделанные друг другом модели?
