Re: [hyades-dev] Model Unification

[Harm Sluiman <sluiman@xxxxxxxxxx>]

Here are my 5 Canadian cents ;-)

As always, this is a healthy topic to
discuss, but all the information needs to be on the table to discuss it.

As I mentioned to Joe, this topic should
be lined up for a specific discussion by all the interested/affected parties.
We can have this discussion in the cross model call in the next couple
of weeks. 

First off, changing the structure of
the events being sent (the implied impact to execution/runners) is a separate
issue from changing the EMF structure. A change like this does not have
to break everything in the chain. The current execution history event could
be loaded today in the CBE model if that is what we wanted a loader to
do.

Second, there is already work underway
for 1.2 and mostly in place to be able to associate, in context, a CBE
with a trace or execution history model. Cross linking was identified a
while back as a requirement, and was put in plan, and is being done at
the model level. This will generically allow context based linking across
model instances.

That said, I fundamentally don't agree
with this proposal. We could turn any model into a network of name/value
pairs but we all know how that scales. We need well structured and typed
models so we can keep the foot print down as much as possible. We already
stress EMF beyond it's memory mgmt abilities and are doing work with the
EMF team to address that. We don't need to make our models even more abstract
and larger for the sake of commonality that needs to then be specialized
in the viewers anyway.

As for extending the CBE log viewer/analyzer
to deal with execution histories in a meaningful way, that is not a loss
to the end user, is something I don't understand at a practical level relative
to our current views. Another specific topic that could be lined up for
discussion.

In addition, the CBE model itself has
flaws that are being worked on by the CBE team, and it is aligned with
an Oasis standard proposal and will likely adjust as that proposal is ratified.
I t has a fundamental purpose, and it will be tuned for that purpose. The
CBE discussions in fact have touched on the reuse of the trace model in
order to not overly generalize the structure of log data when it could
conform to a trace.

As for "can we make such a breaking
change" in the first place, I would suggest not with ease, and not
without a lot of review and planning, as well as migration aids. And only
on a major release boundary if ever.

The orthogonal discussion of unifying
trace and history, and in fact the merging of trace/test/UML2 are important
design discussions to have when we are ready to entertain them. Just as
Serge has tried to do here, a proposal and rationale need to be brought
forward for thorough review. We have a design point at this time for each
of these domains. Traces can be "transformed" into test definitions,
and after the UML2 project is published and hardened we will review the
linkage of behaviour with our other models. As for execution histories
being merged with trace, we do have the ability to link a trace to a history
as mentioned earlier, and need a concrete design issue/requirement to address
in order to make further integration changes.

Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,  
phone:905-413-4032   fax: 4920  
cell: 416-432-9754
mailto:sluiman@xxxxxxxxxx
Admin : Gabrielle Chapman chapmaga@xxxxxxxxxx  Tie: 969-2323

Michael.Norman@xxxxxxxxxxxxx
Sent by: hyades-dev-admin@xxxxxxxxxxx

11/07/2003 06:13 AM

Please respond to
hyades-dev

To	hyades-dev@xxxxxxxxxxx
cc
Subject	[hyades-dev] Model Unification

There's a proposal floating around in the Test Model
Group to abolish 
the Test Execution History Model and use the Log Model instead.  The
discussion is in the minutes of the Test Model Group but it strikes me
as something that might be usefully flagged up to the project as a 
whole. The underlying point is that we have too many models, or rather
too little commonality between the models, and when we build 
model-specific tools we may need to do major re-factoring if we 
subsequently unify the underlying models.

However we dress this up, it is a breaking API change.  Are we allowed
to do this?  does anyone care?

Is this the right unification to make, or should we be trying to unify
the Execution History with the Trace Model, through some "missing
link" 
which could also form the basis of non-Java traces (such as those used
to build HTTP Tests), and possibly even eventually unify Test and Trace
Models?

Those of you who know the history know we did a load of navel gazing 
about this stuff and then decided it was too hard, too bound up with 
UML2 which was still half-baked and which wasn't well handled by EMF, 
and we needed practical solutions in the short term.  What is the
process and time-line for re-opening the discussions?

Mike

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev