Hi carla why do you need to pass a block?
> > > You will notice that what I've got so far is: > • Drawing the classes involved in the evaluation of that block, with > the messages that were sent during that block > • Drawing the superclasses involved along with the inheritance arrow. > Superclasses are included only if there are inherited methods excecuted. > • Drawing the association relationships between instances! That's my > favorite part, and the one that was not trivial to achieve. The code still > sucks, but it's working. You can see that the association relationships > between the Ship, the Pirate and the Mission are drawn, and Collections are > 'skipped' as in a regular class diagram using the cardinality annotation * > over the arrow. > What's interesting about this last point, is resolving these (still pending) > issues: > • If an object form class A has a collection where the elements are of > different classes, or if it has an attribute that could point to different > polimorfic objects, there should be just one association arrow from class A > to: > • the superclass of those different classes, or > • the inferred type those different classes share: this comes > along with some questions, like 'what will the type name be?' > • What will be the scope of the diagram? Objects can have attributes > ponting to numbers, strings, blocks, booleans, etc. Are we interested in > showing those classes in a class diagram? usually it does not really work to display primitive types using arrow a type annotation of the instance variable would be enough. A design diagram is usually focusing on relation between domain entities > I guess, it depends. The diagram scope should not be hard coded (as it is now > :P), because if we want to document a core package, some core classes will > have to appear instead of being ignored like we would prefere in a 'domain > specific' diagram. > • Collections are 'skipped' in the diagrams. That means that if an > object A points to a collection, that points to several objects of class B, > in the diagram only the classes A and B are shown with the classical 'one to > many' arrow. This will mess up diagrams of the collection packages themselves > :P > So, I invite you to think about how could these issues be resolved, and also > play a little bit with what I've got so far, executing [your block code] > asClassDiagram openQuickView. > > I hope that the GSoC project of Santiago will help with the type inferences > part :) but if you do a dynamic analysis then you already get the concrete type of objects so you will not gain much more. Can you show us the way nodes are created? I mean that is the model because what I would like is a class and relations model that we can navigate to draw morphic or other objects. Stef > > Cheers! > Carla. > >
