[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] Model Unification

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
Admin : Gabrielle Chapman chapmaga@xxxxxxxxxx  Tie: 969-2323

Sent by: hyades-dev-admin@xxxxxxxxxxx

11/07/2003 06:13 AM

Please respond to

[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

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?


hyades-dev mailing list