[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] First shot at impact analyzer doc
|
Hi Axel
The diagrams are crisper, but still lack lines from my understanding of
UML, but perhaps they are not UML diagrams. You need to define your
notation. I recall that my PhD supervisor insisting that every diagram
notation must be defined. The big advantage of UML, is that "UML" is an
adequate notation definition.
In my experience diagrams serve three purposes:
a) design aid: the pain of drawing assists the draughtsman in clarifying
ideas. Other viewers do not experience the pain and so may fail to
appreciate the rationale/beauty that is obvious to the draughtsman.
b) publication: multiple concepts are combined to save diagrams and
topology is abused to save space. These diagrams are usually hard to
understand. In the same way that equations need elaboration of missing
steps, published diagrams probably need redrawing to understand them.
c) education: the drawing tells a simple story. These can be really
useful but are hard to do.
Words have a natural order, so readers naturally read the story left to
right, top to bottom.
Pictures do not have a natural order, so viewers do not know where to
start. It is good to impose a primarily top to bottom and/or left to
right order to provide the story framework upon which detail can be hung.
It can be confusing to combine multiple stories in one diagram. It is
usually better to have separate diagrams for some/all of:
inheritance (an implementation convenience)
composition/reference (the static object/state architecture)
construction (the system start algorithm)
destruction (the system stop algorithm)
messages/sequence (an algorithm flow)
Meta can be particularly confusing. Sometimes it is important to have
two or more levels on one diagram. If so it is good to have a very
strong horizontal/vertical boundary to separate the levels. e.g. The
horizontal axis for composition/reference and the vertical axis for
meta-levels.
Regards
Ed
On 21/02/2011 20:19, Axel Uhl wrote:
I updated the diagrams and the sizing instructions for the img tags in
the html. Can you please check if the images look better for you now?
Thanks,
-- Axel
On 2/21/2011 5:58 PM, Ed Willink wrote:
He Axel
I could not understnad the EMF edior integration at all. This clearly
needs at least a screen shot and possibly some Object Diagrams too.
Screen shot of an editor or screen shot of the code showing how to
implement the integration?
Screen sot of the ditor might enable me to know what the added
functiionality is so that I could then comment more usefully.
---
The diagrams help a bit., but
a) Your diagramming tool seems to lose lines in the PNG, making thew
diagrams very hard to understand. The ImpactAnalyzer with two horizontal
lines looks like a Jackson data store. Even the bits that are there are
confusing.
b) The <<produce>> seems to indicate a dynamic relationship that is
completely anomalous to all the others.
It is unclear to me what is adapted.
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?
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.
As you can see, I'm not getting very far.
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3457 - Release Date: 02/21/11
