Model evolution and Phasing

[Paolo F Cantoni]

Hi,

As I improve the emitter interface,  I started to wonder about a problem that I've considered previously.  How can I show how a model will/has evolved over time?

In other words, would it be possible to, in effect, simulate a timeline such that with a little bit of ingenuity, I could show a viewer, this is what the model looked like last week, this is what it looks like this week, this is what it will look like next week...

It struck me that if we change the definition of the Phase property from simple Phase to Effective Phase, and add another property Ineffective Phase, then I could render only those things that were effective for a given phase.  That is, render only if Effective Phase <= rendering Phase <= Ineffective Phase.  ?

Thoughts anyone?
Paolo

[davisford]

Phase property -- seems like a good idea to me for a small model, but too much overhead for larger models.

It seems to me you're using the wrong tool for the job.  Set up version control (hint: Subversion), and version control chunks of the model -- which will provide detailed logging and history of what has changed.

[thomaskilian]

Using version control for a single person doesn't seem to be obvious at a first glance. However, it is unavoidable if you have a need for what you want, Paolo. So I'm totally with Davis, that you should use a version control. And also I like to  advertise subversion You can run it with nearly zero effort on your laptop. I have a small (!) server to hold the repository and it is a) save and b) allows tracking of changes (when did I do what).

[Paolo F Cantoni]

Using version control for a single person doesn't seem to be obvious at a first glance. However, it is unavoidable if you have a need for what you want, Paolo. So I'm totally with Davis, that you should use a version control. And also I like to  advertise subversion You can run it with nearly zero effort on your laptop. I have a small (!) server to hold the repository and it is a) save and b) allows tracking of changes (when did I do what).

Thanks Thomas and Davis,

I'm fully intending to use version control to manage the evolving state of the repository - so we're in violent agreement on that!  
What I'm investigating here is the ability to render information about planning... For example, I may have a CIM, a PIM and 3 PSMs in a given repository.  Using Agile techniques I may want to show that some parts of the CIM aren't fully fleshed out yet (they're likely to be analysed in Phase n+3).  Similarly with the PIM and PSMs.  I'd adorn them differently depending on what I'm trying to show...

Does that explain things better?

Paolo

[sargasso]

I agree with Paolo here!  And would add that this is IMO a larger issue than first appears.  Both UML and EA reflect a very static approach to evolution planning.  In particular, there often exists viable interim deployments of a system and the only way to effectively communicate the issues particular to alternate deployment approaches is outside EA.

I have tried several approaches,  the most effective I have found is unfortunately the most effort intensive on the part of the modeller.

Neither is the problem limited to structural aspects of a system.  Both internal (feature level) behaviour and interactive (element level) behaviours can often be different at different points in an evoltuionary deployment.  For example, lets say that at release X the system will not support "online credit card charge" and that this is to be introduced at release X+n.  between X and X+n there are impacts on the model at all levels - from business process models through to deployment, component and even lower level models.  Yet there are considerations that must (should ) be taken into account at rel X or perhaps even at X-m.  For this reason alone the "model represents a single release" paradigm fails.

So far, the only effective use of the phase field that I have found is for external requirements elements - phase representing the release at which the requirement will be satisfied.

Finally, Paolo's point about "ineffective phase" of a model thingo (a technical term that means all things in a model including elements, features, links and non-UML contents) is equally important.  At specific points in an evolutionary deployment model thingo's can be removed as well as deployed!

Anyway, somehow I cant see a solution to this appearing in the near future as it is IMO a problem with UML itself as well as EA.

bruce

p.s.  On reading this I haven't made myself too clear - there are two problems -
a) representing temporal differences i.e. what changes between different releases/deployments of a system, and
b) representing alternate strategies, i.e. presenting different temporal deployment strategies.
Neither of these is supported too well by UML/EA.

[Paolo F Cantoni]

I agree with Paolo here!  And would add that this is IMO a larger issue than first appears.  Both UML and EA reflect a very static approach to evolution planning.  In particular, there often exists viable interim deployments of a system and the only way to effectively communicate the issues particular to alternate deployment approaches is outside EA.
[size=13][SNIP][/size]

How about putting the alternatives in different namespace packages.  You'd need to write some cloners (or transforms) but...

Paolo

[sargasso]

Yep, that's one of the labour intensive approaches!  

bruce

[davisford]

Paolo, it seems to me what you are referring to is "configuration management" -- see http://www.faqs.org/faqs/sw-config-mgmt/faq/ for defintion of what I mean at section 1.2.

I don't necessarily think that a tool like Subversion does SCM well, but it does do version control very well.  What you need is a strategy/tool that integrates with version-control to plan/deploy/track change.  

Where I work currently they deploy a change management tool.  It is web-based.  In it, you define a task that needs to be accomplished, and it ties directly to some artifacts (i.e. source code / part of model) that are version-controlled.  The developer then checks this stuff out, does the work, completes the task, checks it in.

If you had such an environment set up, you could define completion of a new PIM, associate it to a version control section of the model, and a process/plan/timeline for completing the work (next phase of the project).  This, of course, assumes you can break the model up into manageable units.  It becomes much harder when multiple people need to work concurrently.

[jeshaw2]

Not to mention the issues you get into with feature availability at differing licensing levels

Watch out for Feature Creep my friend