Instance doesn't update from change in element

[ssands]

So, I have a component. I create a diagram and place an instance of the component on the diagram. So far, so good.
Now, I want to add some information to the component (e.g., notes or a stereotype, because I have found out some new information).
Once the component has been modified, I do not see the change in the instance of that component.
Is this a bug? If not, how would I get the instance to update properly?

[Eve]

I don't think it should update. They are different elements.

My question is why do you want it to?

[ssands]

Thanks for the reply.

We are modeling As-Is and To-Be. There are common elements between the two, but in some cases, the relationships between them change.

So, I do not want connections in the As-Is showing up in the To-Be, but there are aspects of the component that I do want to carry over (a stereotype for example, or notes).

[qwerty]

I don't think it should update. They are different elements.

My question is why do you want it to?

Interestingly if you add a method to a lifeline it will be added to its classifier (which makes pretty much sense). So object and class are different, but not that different. Maybe a modification to an object should somehow be routed to its classifier?

q.

[Eve]

We are modeling As-Is and To-Be. There are common elements between the two, but in some cases, the relationships between them change.

It's a common problem how to model as-is vs. to-be, and you've chosen an interesting way to try to deal with it. Unfortunately, I don't think it's going to work because instances mean something different to their classifier and at times they behave differently.

The best way to deal with the problem that I've seen is to have two models (possibly with controlled packages between them.) It's not perfect, but every method I've seen or have thought of has its drawbacks.

[ssands]

We haven't chosen to use instances but are struggling as how to best present the models. I don't want to have two component packages (one for as-is, and one for to-be) for all the usual reasons of updating notes, stereotypes, tags, etc.

I don't see how controlled packages would solve this, but perhaps I am missing something? (All our packages are under version control).

I have to keep the connections between elements separate for each model.

I was really hoping there was a best practice / pattern for this.  

[Eve]

Controlled Packages allows you to have two models and because the guids are constant you can compare between them and and choose when and how to move information between the two.

As I said, it's not perfect, just the best I've found. There's no best practice, because as far as I'm concerned it's still an open problem.

Another way of doing it would be to use diagram filters to show restrict visible items to the "as-is" or "to-be" sets.

[ssands]

Simon, thank you for your reply.

I wanted to clarify a concept you mentioned.

When you mention "controlled package" are you referring to a version-controlled package (e.g, thru SVN) or are you referring to a different aspect of Sparx EA (that I am likely overlooking).

Thanks!

[qwerty]

A controlled package can be version controlled manually or automatically. In the latter case you connect to a VC system like SVN. in the first case you need to save manually and do the VC stuff externally.

q.

[Eve]

A controlled package can be version controlled manually or automatically. In the latter case you connect to a VC system like SVN. in the first case you need to save manually and do the VC stuff externally.

Yes, that's exactly what I meant.

[Scott Lindner]

I have the same question but for different purposes. My situation is to model a very large set of independent systems and subsystems that are each deployed in similar, but different, configurations on different networks. The relationships between these components is always the same, but some components may or may not be present.

My goal is that when I change the behavior or relationships of the abstract components, that those changes are reflected in the instances of the component on component diagrams and deployment diagrams. How does everyone else handle this situation?

[qwerty]

Instances do not have any relations from their classes. Where should they come from? Classes have just relations to classes. Any such relations between instances must be created manually. So how would you reflect an association change in a class to their instances?

q.

[Uffe]

This all goes back to EA vs CM, and the core issue is branching.

You want two (or more) separate tracks of model development, with the ability to keep certain things common and to move changes between the tracks.

In source code management, this is everyday stuff. But while EA can manage package-level check-in, check-out and revert, it simply does not do branching.

My recommendation for version management in EA is to use the built-in baseline functionality rather than an external version control system like Subversion, certainly if you're working with a DBMS repository. Both work on the package level and both are based on XMI files, but baselines are stored within the EA repository and there is no external tool involved.

The main advantage is that baselines allow you to do visual diffing of model contents, which external version control doesn't. The main disadvantage is that package-vs-baseline status is not displayed in the project browser.

Baselines can also be imported/exported between projects, and changes from a baseline can be selectively merged into the project (importing a baseline is a separate activity from merging its contents). This is essentially what the reusable asset service introduced in EA 11 does.

This can be used as a way to achieve branching: copy the entire project and move baselines back and forth between them. I'm not aware of any way to achieve (robust) branching at anything lower than whole-project level, although the reusable asset service might be of help there -- I haven't used that in anger yet.

I have previously implemented the whole-project-branching strategy, and I have also (for a different client) built a solution based on tags and a lot of Add-In trickery. Another approach is to use Change elements extensively together with the Phase and Status fields, but have the components etc contain only the "as-is" version until some milestone where you go through the entire model and update it to become the new version (works fairly well for requirement models, but not for much else).

Either way, you can get to the "acceptable" level but it'll never be as slick as branching in a version control repository.

Where do I send my bill for $.02?


/Uffe