[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] First shot at impact analyzer doc
|
Very strange. The diagrams looked OK when I viewed them in the Help
viewer. I'll re-check.
b) The <<produce>> seems to indicate a dynamic relationship that is
completely anomalous to all the others.
What's a better stereotype to show that the one is a factory for the
other? <<create>>?
It is unclear to me what is adapted.
Well, Adapter is what in EMF receives Notification objects. I didn't
want to introduce a new name for it. I also find the EMF naming somewhat
confusing, but I decided to stay with it
1) because every EMF user should be familiar with this
2) it's what readers will find when looking at the APIs
The diagram confuses two meta-levels.
The OCLExpression refers to meta-model elements of the model elements in
the ResourceSEt, so is the adapter on the Expression, or is it a
prototype for an adapter on each model element, or is the expression
cloned per model element?
I don't think that the diagrams confuse meta-levels. Please also check
the APIs. The ResourceSet isn't necessarily the one that is home to the
OCLExpression elements. It's home to the elements *constrained* by the
OCLExpressions. That's why the EventManager instance is hooked up to
such ResourceSets: it want's to be notified about changes to objects
whose state may affect the evaluation results of the OCLExpressions.
As indicated by the diagrams (give or take the disappeared lines issue),
there can be a distinct adapter per OCLExpression which provides an
implementation for what is to happen when the expression for changes of
which it's registered may have changed its value for some context
objects that the Impact Analyzer determined. So, usually, n adapters for
n OCLExpressions with n ImpactAnalyzer objects that produce n
EventFilter objects that are registered with a single EventManager which
is hooked up to at least one ResourceSet (typically the one of the
EditingDomain of an editor). Where, do you think, do the diagrams say
something different?
In the code snippet new AdapterImpl deserves to be a top level object,
since the Adapter is a critical part of the framework. Anonymoizing it
is an option for practical rather than exemplary code.
IMHO anonymyzing it keeps the change handling code closer to the
registration code which for exemplary purposes I find more useful. In
practical implementations users may of course choose to have separate
named Adapter implementations, but I'm sure they'll know that themselves :-)
As you can see, I'm not getting very far.
Sorry, I'm really trying to find out where/why you fail.
Best,
-- Axel
