Hi Carla, I've just tried in Pharo 1.4 (Moose distribution), I get an error: -=-=-=-=-=-=-=-=-=-=-=-= This package depends on the following classes: CategoryDiagramsHolder You must resolve these dependencies before you will be able to load these definitions: ConnectableShapesDocumentation connectableBounds connectableShapes inheritanceforConnection inheritanceforDiagramNode inheritanceforDiagramNodeMorph DiagramDrawingDocumentation connectableshapes inheritanceforConnection
Select Proceed to continue, or close this window to cancel the operation. -=-=-=-=-=-=-=-=-=-=-=-= I would be glad to try again. Cheers, Alexandre On 8 May 2012, at 05:37, Carla F. Griggio wrote: > 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. > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
