Hi everyone!
I've been doing some experiments to get Class Diagrams generated from the
evaluation of a block. There's still a lot of work to be done, but I've
just got this working and I wanted to show it to you :)
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.
