Gofer new

� � squeaksource: 'smallUML';

� � package: 'ConfigurationOfSmallUML';

� � load.

((Smalltalk at: #ConfigurationOfSmallUML) project version:'1.1.6') load.

After downloading the project, try this example:

[|jack william blackPearl questMission|

jack := Pirate new alcoholLevel: 0.7; items:#(#compass #islandMap #rum #moreRum #goldMedallion).

questMission := TreasureQuest new.

blackPearl := Ship new.

blackPearl mission: questMission.

blackPearl acceptIntoTripulation: jack.

] asClassDiagram openQuickView�

A messy and 'overlapped' diagram will come up, because there's still no autimatic positioning of the diagram nodes :( but you can drag the class boxes around to place them anywhere you want.

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? 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 :)

Cheers!

Carla.