Modelling future, present and past states... The "Effluxion of Time"

[Paolo F Cantoni]

As suggested, I've started a new thread to discuss what might be needed for Enterprise scale modelling of multiple states in time.  This post address the concepts involved so we can agree on what we are talking about and then look at options for implementation.

Time flows (for us humans at least).  What we consider to be the "present" state changes over time.  In database architectures, we can handle how records change over time with State Episodes (the record was in this state for this episode of time).  Using State Episodes, we can hold both historical changes of state and proposed future state(s) in addition to the present state.  One thing we can't do is hold alternate future states (at least not with standard State Episodes).

Because of the effluxion of time, there is only one present state and one "thread" of historical states.  With Standard State Episodes, one can hold a single "thread" of future states.

Historical states are (supposed to be) immutable.  The past is the past!  Whereas, the future is subject to change.  To quote Neils Bohr (disputed), "Prediction is difficult - especially about the future!".

The present is just the present - "As Is" - although what it contains changes with the effluxion of time.

Using state episodes, one can query the object and determine its state at any point in time, seamlessly.

One of the changes that the future is subject to, that that of alternate planning.  In real life (and therefore in modelling), we need to handle alternate, competing, possibilities for a solution while we are investigating the problem and its possible solution(s).  Eventually, we hope, one solution will win out and will be adopted as the "To-Be" solution, which when implemented and the effluxion of time has caught up with the future will become the new "As-Is".  One might say, in addition to a "To-Be",  we also need several "Might-Be".

While Sparx EA does not actually hold state episodic data, it utilises the single thread concept as part of its time aware modelling.

EA uses the concept of doppelgangers or clones to (at least some extent) simulate state episodes.  While not able to achieve the seamless determination of the object state at an arbitrary point in time, a clone (version) of the object is created at nominated points so that changes in a specific version are not also made in other versions.

Unlike a state episodic item, there is no single "identity", rather the single "thread" of clones establishes how the item has changed in each version.

In real life (and therefore in modelling), we need to retain knowledge of "As-was". There is a conceptual difference between "As-Was" and the other two viewpoints.  "As-Was" as mentioned above is immutable. We'd like to be able to recreate the state of an item at any point in the past for which we were tracking it, but that's not possible.  We can only take a "snapshot" of the item at a point in time.  Thus, we aren't really creating an "active" clone of the present (at the point at which we took the snapshot), but a "frozen" doppelganger.  It seems to me, therefore, that the semantic relationship between the past doppelgangers and the present is distinct from that of the future clones and the present.  In addition, while there is no direct relationship between the past doppelgangers (since they each came from a snapshot of the evolving present) there is an inferred relationship between them.

In EA, we already know how to create snapshots, we just export the branch and re-import using "Strip GUIDs".  All we need to do is to link the doppelganger with its master.  Not hard to do if we add a Tagged Value holding the original, master, GUID before export.  We can use the same GUID to link the other past doppelgangers to the new one.

Thoughts?

Paolo

[Sunshine]

Good to see someone thinking about this prickly problem in Sparx EA. I remember having a conversation way back in 1997 with Popkin for System Architect to support such a feature - unfortunately it was too hard for them. It was the relationships between the elements that was the tricky part. 

I like your idea of using a GUID to link back to the original element with a tag value and in addition taking a leaf from Martin Fowlers work on temporal patterns you could add a date range of when its active. Here's the link to Martin Fowlers temporal patterns
https://martinfowler.com/eaaDev/timeNarrative.html.

I guess it would be possible to do the same thing with the connector too.

[qwerty]

I strongly doubt that "time aware modeling" is of any use at all. I had much fun reading DeMarco's "Deadline". And clearly nobody has the money to work that "agile way" he describes. What I see is just to have a goal and steer towards that. Nobody is interested in past paths that have been taken. And also quite clearly nobody can afford taking parallel paths to find the optimal way to the set goal. What counts it the NOW and everything should be done to give a clear picture of this. Nothing else.

My 2 cents.

q.

[Paolo F Cantoni]

I strongly doubt that "time aware modelling" is of any use at all. I had much fun reading DeMarco's "Deadline". And clearly, nobody has the money to work that "agile way" he describes. What I see is just to have a goal and steer towards that. Nobody is interested in past paths that have been taken. And also quite clearly nobody can afford taking parallel paths to find the optimal way to the set goal. What counts it the NOW and everything should be done to give a clear picture of this. Nothing else.

My 2 cents.

q.

For smaller projects, that may be the case, but in an enterprise setting, where "Corporate Alzheimer's" sets in, there is merit to making the immutable past available.  In addition, in bureaucratic institutions ("no names, no pack drill") there is a necessity to not only consider alternatives but also to show they have been considered...

Also, I'm not necessarily talking about "Time-Aware" modelling, since it can't achieve what we need.  Perhaps I'm talking about Temporal State/Version Management.

Paolo
Paolo

[Paolo F Cantoni]

Good to see someone thinking about this prickly problem in Sparx EA. I remember having a conversation way back in 1997 with Popkin for System Architect to support such a feature - unfortunately, it was too hard for them. It was the relationships between the elements that was the tricky part. 

Yes that's what we think also.  However, at least it's doable with EA.
[/quote]I like your idea of using a GUID to link back to the original element with a tag value and in addition taking a leaf from Martin Fowler's work on temporal patterns you could add a date range of when its active. Here's the link to Martin Fowler's temporal patterns
https://martinfowler.com/eaaDev/timeNarrative.html.

I guess it would be possible to do the same thing with the connector too.
[/quote]THe GUID is there just to preserve the relationship between the doppelganger and the master.  Once the doppelganger is imported, we use the GUID to create the arc back to the master.  Since the semantics of the past snapshot are different from the future clone, one can imagine a RefGUID in the Master identifying the last snapshot taken.  One can then create the link between the latest snapshot and the previous snapshot.

I met Martin in the early 90's when we both spoke at a Conference in Sydney.

Paolo

[Paolo F Cantoni]

Well, this seems to have died a quick death!

Does that mean we've nailed it?

I'm keen for others to suggest scenarios that we can test against our proto-design.

Paolo

[Nizam]

Hi Paolo
I was waiting for some senior stalwarts to share suggestions. Whilst I'm amazed by the line of thoughts, my idea of a Time Aware modeling is slightly different.
Maybe I had the implicit Bias towards diagrams and the available features in EA.
My Idea was

• Ability to further the baselining capability to be more granular, preferably at a diagram level
• Provide an improved 'Diagram compare to Baseline' utility to compare a diagram / package / element or even tagged values to previous versions
• Improve, or make the merge utility more intuitive and simpler to be able to go from diagrams (instead of drilling through n levels)

I've used RAS as an effective way to manage CURRENT STATE and many parallel R&D repositories, however, the diff / merge, automation capability, diagram compare and slowness in merge has been deterrents.

There are some interesting innovations like https://www.lieberlieber.com/lemontree/en/ which are trying to solve the problem along this line.

Just my 2c

[Glassboy]

Does that mean we've nailed it?

I started thinking about how your summation was predetermined by the grammatical tense in English and sunk slowly and quietly into a epistemological fugue state.

[Paolo F Cantoni]

Does that mean we've nailed it?

I started thinking about how your summation was predetermined by the grammatical tense in English and sunk slowly and quietly into a epistemological fugue state.

Surely you "sank into an epistemological fugue state".   

Paolo

[Glassboy]

Does that mean we've nailed it?

I started thinking about how your summation was predetermined by the grammatical tense in English and sunk slowly and quietly into a epistemological fugue state.

Surely you "sank into an epistemological fugue state".   

Does one mean the simple past irregular verb, how does one know?

[Geert Bellekens]

Using version control we can achieve some of these requirements already.
- Investigate a previous (AS-WAS) state (create a branch based on a certain date and restore that to (a copy of) the model)
- Create different alternative MIGHT-BE scenarios (again using different version control branches in different models)

The major difficulty is Merging

A very common scenario would be to have

- An AS-IS (and maybe partly TO-BE) model that is actively maintained. Let's call this the main trunk.
- Multiple branches for possible alternative MIGHT-BE models

Things that are currently very hard (practically impossible) to do:
- Update a MIGHT-BE branch to contain the latest changes in the main trunk (in order to not get too much behind in the branch)
- When a MIGHT-BE scenario has been chosen, merge it back into the main trunk. (or do the update above and call promote this branch to be the main trunk)

I think the LemonTree tool from LieberLieber addresses this problem (and that of three way merges), but I'm not sure if the overhead that comes with a tool like that is acceptable is most scenario's.
I can't imagine people wanting to spend days looking at thousands of differences having to decide to go left (trunk) or right (branch).

If this problem is to be solved there should be a very intelligent merge engine that somehow manages to keep the overhead (and thus the need for human decisions) to a minimum.

I'm not even sure if this is doable, even in theory.

Geert

[Paolo F Cantoni]

Does that mean we've nailed it?

I started thinking about how your summation was predetermined by the grammatical tense in English and sunk slowly and quietly into a epistemological fugue state.

Surely you "sank into an epistemological fugue state".   

Does one mean the simple past irregular verb, how does one know?

One learns the "Queen's English" and then one is aware of the appropriate form to be used.  One would not want to be considered a member of the ηοί πολοι (hoi poloi) 

Paolo

P.S. Yes, I did do Latin and Greek in High School. 

[Paolo F Cantoni]

To Geert's points, if I understand them correctly, they rely on multiple instances of the Repository.  I guess one of my (implicit assumptions) was that there was ONLY one repository.

As part of our possible future solution description, we have a "Transition diagram", where we place the model items (vertices and arcs) in the current state. We then add the future items and connect the current and future things with a "Transitions to" relationship.  With EA recent ability to allow relationships between relationships and relationships and items, we can specify what the transition will be to the requisite level of detail.  It's a really easy way to see if we've "considered everything".

Consequently, we need to maintain all versions in the one repository to allow us to map between them.

Paolo

[Geert Bellekens]

To Geert's points, if I understand them correctly, they rely on multiple instances of the Repository.  I guess one of my (implicit assumptions) was that there was ONLY one repository.

As part of our possible future solution description, we have a "Transition diagram", where we place the model items (vertices and arcs) in the current state. We then add the future items and connect the current and future things with a "Transitions to" relationship.  With EA recent ability to allow relationships between relationships and relationships and items, we can specify what the transition will be to the requisite level of detail.  It's a really easy way to see if we've "considered everything".

Consequently, we need to maintain all versions in the one repository to allow us to map between them.

Paolo

Using different repositories is more of a workaround then an actual requirement.
Having one repository where we could maintain all versions would be ideal.
But in that case the tool would have to support that in a transparant way.

For example, if I want to query all use cases I only want to see those of the branch I'm working on, not the ones from other branches (unless specifically instructed)
Or if I want to set the type of an attribute, I only want to be able to select classes from the same branch
Or... etc..

Seems like you should be able to set the context you are working in (MIGHT-BE alternative X) and the tool should then support this in such a way that you only work with elements that are in that branch.
I can imagine that would be a serious challenge to implement that properly in a single repository.

Geert

[Glassboy]

As part of our possible future solution description, we have a "Transition diagram", where we place the model items (vertices and arcs) in the current state. We then add the future items and connect the current and future things with a "Transitions to" relationship.  With EA recent ability to allow relationships between relationships and relationships and items, we can specify what the transition will be to the requisite level of detail.  It's a really easy way to see if we've "considered everything".

You've discussed the what but not the why.  I suspect that that no one who has commented so far has the same reason for wanting time aware modelling, or potentially for the same notation (where).