Time Aware Modelling - Some questions

[Paolo F Cantoni]

The new Time Aware cloning process looks very interesting.  I've read the white paper, but I am still unsure if we can use it in our environment.

This post is primarily addressed to the Sparxians, but if any user has experience or knowledge, please feel free.

First question, does the version numbering need to be numerically based?  The implication is that it doesn't but can anybody confirm?
In our case, we use the version field to identify which project the item belongs to - we could extend this to include another part to indicate as-is vs to-be (in that project)

There is an implicit assumption that all the resources to be cloned are in the same branch structure in the repository.  For example, the Glider Control System branch contains the items, diagrams and packages to be cloned.

In an enterprise-wide environment, this is often NOT the case.  In order for items to be easily found by users (and, more particularly, our automatons), they are collected into a standard structure (separate from the diagrams that use them).

In our case we have a number of branches with items within them - for example, Enterprise wide, per-project, Integrating (across the Universe of Discourse).

Most often, we have sub-branches that consist only of diagrams.  We might want to use the Clone Structure as New Version to create the clone of the folders and diagrams.  But as I understand it, the diagram would still consist of pointers to the original elements.  Is that correct?

If that is the case (which is NOT a problem in and of itself), then if the user wanted to change the element (in the to-be diagram, they would use the Clone Element as New Version to create them as needed - and then change the clone.  Obviously, there would need to be security to stop the user changing the wrong version - but I don't think that's insurmountable.

Thoughts?  Suggestions?
TIA,
Paolo

[YogaMatt]

Hi Paolo

Lots of views on this post, but where are the replies?

• Version numbers need not be numerical.
• The clone of diagrams does consist of pointers to original elements, but then you can optionally clone those elements in-situ from the diagram, when you are intending to change them from the prior version.

Have you gone on to use this approach? I'd be interested in your experiences.

Consider a cloned V1.1 diagram with a V1 element 'X' that relations to a V1 element 'Y', with a V1(X-Y) relationship.
I don't like the fact that when you clone V1-X, it creates a V1.1(X)-V1(Y) relationship, nor do I like the V1.1(X)-V1(X) relationship.

To Illustrate why I don't like it, consider what happens to a document of your V1 AS-IS that reports on relationships. All of a sudden it is polluted with V1.1 etc version object ends. And also bear in mind it will likely report on the V1.1 'X' through the trace relationship.

It's an interesting implementation but there's another way to skin the cat that doesn't have these issues. I'm taking one idea to the London User Conference on 18 May, where we can workshop the subject and see what other ideas people have. I pledge to come back to the forum with a summary of the discussion.

Namaste,

Matt

[brback]

First question, does the version numbering need to be numerically based?  The implication is that it doesn't but can anybody confirm?
In our case, we use the version field to identify which project the item belongs to - we could extend this to include another part to indicate as-is vs to-be (in that project)

We've done some testing with time aware modeling based one the same idea you suggest. Meaning we use "as-is" and "to-be" in the versioning, which seems to work out fine. Including the project id might be a good idea as it could indicate if it's actually part of a transition architecture.

Consider a cloned V1.1 diagram with a V1 element 'X' that relations to a V1 element 'Y', with a V1(X-Y) relationship.
I don't like the fact that when you clone V1-X, it creates a V1.1(X)-V1(Y) relationship, nor do I like the V1.1(X)-V1(X) relationship.

To Illustrate why I don't like it, consider what happens to a document of your V1 AS-IS that reports on relationships. All of a sudden it is polluted with V1.1 etc version object ends. And also bear in mind it will likely report on the V1.1 'X' through the trace relationship.
Matt

I wasn't aware of this, but I see how this could be unfortunate. Could this be solved if there existed a versioning/state for the relations? (indiciating if the relations are as-is or to-be)

My biggest issue with time aware modeling is that you get an ureasonable amount of elements which you have to keep track of across states. Does anyone have any good way to handle this?

I think the most reasonable way to solve this is to have only one element regardless of state, meaning you would clone diagrams rather than elements. State is primarly indicated by the relationsships the element has to other elements, meaning there has to be a way to indicate if a relationsship is as-is or to-be. This would also render the relationsship matrix more useful. In an integration matrix you would for instance be able to sepearte if the integrations (relationship between two elements) are as-is or to-be. As far as I know there's no way to accomplish this in Sparx today.

[Paolo F Cantoni]

[SNIP]

My biggest issue with time aware modeling is that you get an unreasonable amount of elements which you have to keep track of across states. Does anyone have any good way to handle this?

I think the most reasonable way to solve this is to have only one element regardless of state, meaning you would clone diagrams rather than elements. State is primarly indicated by the relationsships the element has to other elements, meaning there has to be a way to indicate if a relationsship is as-is or to-be. This would also render the relationsship matrix more useful. In an integration matrix you would for instance be able to sepearte if the integrations (relationship between two elements) are as-is or to-be. As far as I know there's no way to accomplish this in Sparx today.

I don't agree with YogaMatt's point about the additional relationships. I can't see how "you can leave home without them". However, I do agree that here should be some way to indicate that the relationship is a cloned one - for the filtering purposes he mentioned.

I also can't see how you can do without the additional cloned elements.  State Is NOT ONLY indicated by the relationships.  ANY part of the cloned item can change (including its name) so you need to provide the ability to change ANY property or relationship.  The only thing that can't change (and retain the cloning functionality) is the traceback relationship to the master from the clone.  If you change that, you break the cloning functionality.

That having been said (and as I mention in another posting today) what's needed is BETTER support for the relationship between the clone and the master.  We need a Comparator/Merger - most of that is already available by cloning (pun intended) the baseline comparison/merging code.  Support for transparently viewing the properties of the clone(s) from the master (and vice-versa) and so on.  I'm sure Sparx are working on things like that.  IF not, let us know and we'll put in some feature requests.

Paolo

[brback]

I also can't see how you can do without the additional cloned elements.  State Is NOT ONLY indicated by the relationships.  ANY part of the cloned item can change (including its name) so you need to provide the ability to change ANY property or relationship.  The only thing that can't change (and retain the cloning functionality) is the traceback relationship to the master from the clone.  If you change that, you break the cloning functionality.

That's a valid point. We're modelling primarly in ArchiMate, and extend with BPMN, ERD and UML when it's necessary with more details. For ArchiMate the only "property" we could change is name, and perhaps notes/description. Names will rarely change, and if the need for this happen you could add an additonal element representing this, while leaving the other elements alone. Meaning name could be thought of as an unique ID for the element. For the other modeling languages I can see this could be an issue if you're working closer to the solutions continuum, especially in data modeling.

[Paolo F Cantoni]

I also can't see how you can do without the additional cloned elements.  State Is NOT ONLY indicated by the relationships.  ANY part of the cloned item can change (including its name) so you need to provide the ability to change ANY property or relationship.  The only thing that can't change (and retain the cloning functionality) is the traceback relationship to the master from the clone.  If you change that, you break the cloning functionality.

That's a valid point. We're modelling primarly in ArchiMate, and extend with BPMN, ERD and UML when it's necessary with more details. For ArchiMate the only "property" we could change is name, and perhaps notes/description. Names will rarely change, and if the need for this happen you could add an additonal element representing this, while leaving the other elements alone. Meaning name could be thought of as an unique ID for the element. For the other modeling languages I can see this could be an issue if you're working closer to the solutions continuum, especially in data modeling.

We've heavily extended ArchiMate to allow just about all element types to have Features (Attributes and Operations).

Paolo