В процессе работы столкнуться с проблемой ...
Суть:
- Имею развернутую в ЕА 12 Базу данных с таблицами(class diagramm), классами(component diagramm + activity diagramm), представлениями (sequence diagramm + use case diagramm) и так далее...
- Имею проработку механизмов (добавление нового функционала) для последующего внедрения, в результате проработки меняются те или иные сущности

Как проводить актуализацию сущностей в диаграммах, что брать за точку отсчета?

К примеру есть сущность таблица с набором полей Field1, Field2, Field3 по процессу должно добавится еще два поля и к примеру какой то тригер на нее ... и допустим эта таблица используется в неком наборе ф-ционала.

То есть если делаю добавление полей они всецело будут отображены на диаграммах, что приведет к искревлению реальности...

Прочитал два раза, ничего не понял - в чем проблема?

Ладно попытаюсь объяснить по другому ...

Есть две среды
PRODUCTION и DEVELOPMENT
на PRODUCTION развернут ф-ционал
на DEVELOPMENT ведется разработка ф-ционала

в ЕА 12 отстроина структура и бизнес логика PRODUCTION, и отрисовывается по мере поступления задач "дельта" скоупа работ, которую будет выполнять разработчик, по которой будет произведено тестирование

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

Сейчас процесс такой
Есть хранилище объектов

группа бизнес анализа делает смарт копию нужных ей объетов ... тем самым разрушая связи ...
по факту приёма задач я актуализирую данные по скоупу заявок ...

и все вроде понятно ... но это все крапотливая ручная работа!

Вопрос Вы задали реально интересный, правда трудно понимаемый. Давайте его определим на некотором примере?

1. пусть есть диаграмма Х. Ее сделали отработали отрисовали, все красиво и эстетично. Отправили в производство.
2. в стадии разработки(проектирования?) возникает потребность изменить некоторую диаграмму, внести в нее поля и всякое другое.

т.е набор классов скажем одинаковый, а отображение диаграмм различное.
И вот когда меняете диаграмму из пункта 2, диаграмма из пункта 1 искривляется

В этом проблема?

т.е набор классов скажем одинаковый, а отображение диаграмм различное.
И вот когда меняете диаграмму из пункта 2, диаграмма из пункта 1 искривляется

В этом проблема?

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

после реализации процесса приходят задачи пачкой .. и начинаются пляски и выяснения что входит или войдет а что нет в релиз хранилища ..

predator_ua, удалось ли решить вопрос?

Коллеги, поделитесь опытом совместной работы с EA? Часто ли возникают конфликты при внесении изменений в пэкаджи? Каким образом передаете проекты кодерам?

predator_ua, удалось ли решить вопрос?

Коллеги, поделитесь опытом совместной работы с EA? Часто ли возникают конфликты при внесении изменений в пэкаджи? Каким образом передаете проекты кодерам?

В документации есть описания работы в режиме Security когда вы вводите код авторизации и переводите хранилище в режим безопастности, далее вам как админу надо создать локальных админов той или иной папки, выдать все необхадимые доступа и после того как выдаете, забираете у админа группы право на изменение допусков.. далее всех ново заведенных пользователей заводите в ту или иную группу

Да и вот еще .. все диаграммы которые будут привязаны на ту или иную группу видны всем .. но редактируют только те кто может

А если попробовать изобрести такой велосипед:
* Делаем новую диаграмму - релиз такой-то
* В нее добавляем все изменяемые классы
* Делаем независимую копию (клон) этих классов, связываем исходный класс и новый связью наследованию со своим стереотипом
* Меняем копию класса, куражимся над копией, как хотим
* Когда все изменения согласованы - меняем исходные классы и закрываем данную Д для редактирования.

Это будет работать, если не надо менять связи между исходными классами, хотя наверное и тут можно додумать.

А если попробовать изобрести такой велосипед:
* Делаем новую диаграмму - релиз такой-то
* В нее добавляем все изменяемые классы
* Делаем независимую копию (клон) этих классов, связываем исходный класс и новый связью наследованию со своим стереотипом
* Меняем копию класса, куражимся над копией, как хотим
* Когда все изменения согласованы - меняем исходные классы и закрываем данную Д для редактирования.

Это будет работать, если не надо менять связи между исходными классами, хотя наверное и тут можно додумать.

Спасибо коллега за мнение но велосипед не подходит .. С Вашего позволения я поясню почему нет ..
1. При составлении процессов чертится диаграмма к примеру Sequence на нее помещаем "component1" у которого есть ряд переменных и ряд ф-ций
- в самой диаграмме выполняем обращение к тем или иным ф-циям компонента "component1"
2. При построении сценария к use case или же к той же Sequence диаграмме Заходим в ContextReference и добавляем туда нашу компоненту "component1"..
- после чего в сценарии пишем
component1 инициирует что то гдето ...
component1 выполняет контроль ...
вызов каких либо методов из component1

3. При Выполнении анализа работы компонента "component1" выполняем его выбор и ЕА проходит по последовательности ..

----
Теперь по Вашему "Велосипеду" с привязкой к моим кейсам

1,2,3: Вы делаете клон.. то есть не привязанный к реальным схемам .. делаете ему статус "proposed" ну или версию ставите другую ...
и дальше у Вас по процессу он не отслеживается .. но! после приема данной задачи ... нам надо переписать всю подноготную заново!..
- сместить все дополнительные свойства и методы в оригинал...
- перерисовать все диаграммы ..
- пере подвязать их под процессы...

П/С это не решение ... это скорее дополнительная проблема ..