Project Structure and Model Element Promotion

[GMF_TimB]

Good day to Everyone -

We are rolling-out a team environment for Sparx EA.  The Sparx EA project structure contains, among other things, an Enterprise View and Project Views as root nodes.  There will be a model created for each business/implementation project within the Project Views node.

As a normal course of solutions design, we will capture new and existing system components as model elements along with their relationships (which may form reusable patterns).  Some of these components and patterns will be interesting in an Enterprise View, and we will want to share them between business/implementation projects.

All this means that we will likely create "Libraries" of reusable model components and patterns.  This means we will need processes and governance around the acts of identifying and promoting model elements from the Project Views to (perhaps) Product Line Views to Enterprise Views.

We are sure that others have already encountered this, and we are hoping some of them read this forum:-)

What are you doing to facilitate reuse and information sharing between your business/implementation projects?  How are you using EA to facilatate that?  What does your governance of these processes look like?

Thank you for your time and considered thoughts?

Kind regards,
Tim B.
GM Financial

[qwerty]

What I did was to create multiple repositories where shared packages were locked with EA's user security. So each party was able to look into the other parties work and reference elements. At certain points of time those packages were updated from XMI. The problem you will face is to create a hierarchy which has no cycles. Or if there are cycles you have to have procedures which rule the precedence of changes. Also migration of elements from - say a customer to a product package - needs some precautions. Nothing you could describe in a few words. It takes a lot of thinking in the context of your specific domain.

q.

[OpenIT Solutions]

Hi,

The quick answer is to create objects (ie UML Components) in a main library. Then create a package for each project (with appropriate sub-packages for your various arhcitectural views, ie Business Architect, Application Architecture etc). Within the project folder add "instances" of your library elements to diagrams.

As a project goes live - we manually add agreed relationships between library elements (ie components) to the actual elements (ie not the instances). Create child uml diagrams to each component within the library to model these relationships. This way your library elements contain the as-is view of your compoent architecture. You can use the same approach with classes (to say model your domain architecture).

Regards,

Jon.