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.