Как я могу создавать версии программных компонентов в Sparx Enterprise Architect (EA)? - PullRequest
Новая
       70

Как я могу создавать версии программных компонентов в Sparx Enterprise Architect (EA)?

2 голосов
/ 04 июля 2019

Я работаю над моделированием программной системы с использованием Sparx Enterprise Architect 13. Эта система содержит различные версии программных компонентов.Обычно мы добавляем сервисы и / или API, когда выпускаем новую версию программного компонента.

В настоящее время, чтобы отразить тот факт, что компонент ServiceV1 предоставляет интерфейс A, а ServiceV2 предоставляет интерфейсы A (так же, как ServiceV1) иB, я заставляю ServiceV2 расширять ServiceV1.Но это не так просто:

  • ссылка на обобщение недоступна в диаграммах между компонентами, поэтому я должен использовать Advanced> Parent ...
  • , ей не хватает гибкости, потому что я не могупереопределить интерфейс A более новой версией интерфейса

Есть ли лучший способ сделать это? Каков стандартный способ поддержки нескольких версий одного и того же компонента?

Спасибо!

Ответы [ 2 ]

1 голос
/ 04 июля 2019

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

  • На уровне неверсированных компонентов у вас есть только один элемент в репозитории проекта для каждого компонента (не для каждой версии компонента).
  • На уровне версионного компонента у вас есть один элемент в репозитории проекта для каждой версии каждого компонента .

Каждый версионный компонент, например MyComponentV2 имеет «следовую» зависимость от неверсированной, например, MyComponent.

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

Когда вы создаете новую версию компонента, вы копируете самую последнюю версию компонента (MyComponentV2) со всеми его соединениями, включая «трассировочную» зависимость от неверсированного компонента (MyComponent), и даете ему правильное имя. (MyComponentV3).

Я применил это в большом проекте.

0 голосов
/ 05 июля 2019

На самом деле не существует стандарта для моделирования такого сценария.В лучшем случае вы можете иметь соглашения - которые могут отличаться от домена к домену.Однако вот как я бы смоделировал это:

enter image description here

ServiceV2 имеет отношение <<trace>> к ServiceV1.UML 2.5.1 говорит на с.682:

«След» |Абстракция |Определяет отношение трассировки между элементами модели или наборами элементов модели, которые представляют одну и ту же концепцию в разных моделях.Трассировки в основном используются для отслеживания требований и изменений по моделям.Поскольку изменения модели могут происходить в обоих направлениях, направленность зависимости часто можно игнорировать.Отображение определяет отношения между ними, но оно редко вычисляемо и обычно неформально.

Так что это должно означать, что в этом контексте ServiceV2 создается с использованием ServiceV1 (я ранее использовал <<derive>> здесь, так как онказалось логичным. Но на самом деле семантика UML определяется по-другому (см. стр. 680 UML 2.5.1).Вы можете придумать свой собственный стереотип здесь и объяснить его в контексте домена (например, <<version of>>).

Вы, вероятно, создадите копию ServiceV1 или смоделируете ее вручную как новый элемент (вы этого не делаетепо массовому сценарию, а?).Здесь я добавил предоставленные интерфейсы, которые оба реализуют общий интерфейс A.Быстрый линкер не предлагает эти отношения.Вам нужно либо пойти неуклюжим способом Ctrl-I, либо взять реализацию из набора инструментов.

Зависимость <<derive>> не предлагается напрямую (если у вас нет собственного MDG и вы не определили его в QL или на панели инструментов),Таким образом, вы создаете зависимость и выбираете derive в меню стереотипов.

Это широкое поле, и управление версиями не так просто, как простое добавление схемы нумерации.В любом случае, если вы создадите новый компонент, это будет что-то другое.Так что <<derive>>, вероятно, лучший вариант здесь.

Примечание: советник использует строчные буквы <<trace>>, а UML использует <<Trace>>.Просто заметил это.С тех пор советник использовал строчные буквы.Некоторый реликт с тех пор, как UML 2.5 на OMG изменил его на верхний регистр первым символом.Стоит ли сообщать об ошибке?

...