Preserving domain models

[pearms]

I'm new to EA and I'm struggling with what I consider some simple model management.  We have quite a number of domain models which we are taking through the activity modelling stage and on to sequence and class diagrams.  What I want to do is preserve my domain models in some way within the same project (if possible).  I don't see an easy way of doing this within EA.  I can deep copy the diagrams but then I have duplicate objects.  I can shallow copy the diagrams but changes in the class diagram will change the original domain model.

Copying the project or model is not ideal because then I have dual maintenance issues.  Baselining is not ideal either because I do want to make domain changes as future use cases are diagrammed and new domain objects are required.  Am I thinking about this wrong?  It seems EA should provide a way of preserving your domain models as you move forward with your designs, but allow changes as new domain objects are encountered.  Any help would be appreciated.

[«Midnight»]

Just a few thoughts, since I'm sure others will chime in.

First, if you want to have a single 'incarnation' of a given element in your model, you have to live with the fact that a change to that single element will be reflected elsewhere. After all, you've changed it.

But, you can have divide your efforts into phases, such as analysis and design (you can get much finer-grained than that, but you get the idea here I'm sure).

If you want to keep your analysis work separate from later phases (perhaps second-stage analysis in your case), then separate these into (say) a separate view (a package immediately underneath the model root node) The view itself can have structure, including a package hierarchy, so you can set up an entire 'ecosystem' of domain models, or whatever.

When you move to a later stage, do the same thing again. Make new packages and entities in the new phase. You can always start with copies of entities from earlier phases - you'll see why in a moment.

You can now create «trace» relationships between relevant items (at the element or package level) between the phases, so that your audience can trace late-stage entities back to their antecedents in earlier phases.

Now you can modify an entity in either phase, without breaking it elsewhere.

You're still left with the issue of having a modification ripple out across a given phase. This should not be an issue. If other diagrams (for example) are meant reflect the same element, then you should see changes in all cases. If the other diagrams are reflecting something else that looks similar to your original, then make the other instances separate entities, specifically so that changes won't ripple through unrelated entities.

Consider things like inheritance, or perhaps an object model. Often when you are having this sort of quandary it is a sign that you need to be working with a different diagram type.

Hope this gets you started,
David

[peter.zrnko]

I don't understand what exactly you want to have. I think you want to have history of one package (domain model). And how do you want to view this history
- in the same place as the actual version
- in another branch in the same project (different elements)
- in other project
?
And what do you want to do with this history? Do you want to compare it with e.g. actual state?
Or you have some other projects, which use some old state of your package?

I think the best way is to version control your package with Domain model. If this package will be version controlled, then you will have all history in CVS repository and the only problem will be, how to get it out from CVS.
And it is possible to get history out from the CVS. It's not so easy, as EA doesn't support it directly, but it's possible. The way how to do it, depends on what you want to do with the history state of your package.

[Thomas Mercer-Hursh]

It sounds to me like you are modeling your classes directly on top of your domain model instead of having a domain model and a class model.  Really, these should be separate things since it is likely that some analysis will intervene.  If your domain models are a good shot on real classes and you have a specific target language, then just transform the domain class to create the class model as described here http://www.sparxsystems.com/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1191600949
Add the trace relation and you are all set to evolve both.

[«Midnight»]

Thanks Thomas,

You've put this much better, and I'd forgotten the reference as well.

David

[pearms]

Thank you everyone for your prompt replies.  They have all helped put things in perspective for me.  Thomas, thanks for the response, your right on with your assessment and the link helped.  That's exactly what I want to do.  You put it very well, I want these models to be linked but I want them to evolve seperately as further use cases are handled and as the class model matures, the copy and trace relation seems to fit nicely.

Thanks to all!

[Thomas Mercer-Hursh]

As you will notice, it was that thread which helped me to figure out how it should work, so I am just giving back what was given to me.  That's one of the things that makes this a very good community!

[Krzysztof Swiatkowski]

I would see this as a good place to use Transformations. You could create Transformation that can produce congruent model. After that you can modify the transformed model. There are special types of links created internally and they can be seen in Hierarchy window.
Be aware that there are some issues with overwriting changed attributes with new transformations.
Maybe transformation could help you.

[Thomas Mercer-Hursh]

The neat thing is, unless you want to preserve a PIM class model, the transforms are already there for standard language targets.