Smalltalk › Pharo › Pharo Smalltalk Developers

smallUML news: towards autogenerated diagrams

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Carla F. Griggio

smallUML news: towards autogenerated diagrams

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.

Damien Cassou

Re: smallUML news: towards autogenerated diagrams

Hi Carla,

On Tue, May 8, 2012 at 11:37 AM, Carla F. Griggio
<[hidden email]> wrote:
> 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 :)

what about some screenshots to help us get a feeling of what you did?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

Carla F. Griggio

Re: smallUML news: towards autogenerated diagrams

Sure, here you are. This would be the diagram of the example I suggested.

This is a "quick view" of the diagram, I still need to figure out a better way to save and organize diagrams of a project/category/package, etc

On Tue, May 8, 2012 at 6:42 AM, Damien Cassou <[hidden email]> wrote:

Hi Carla,

On Tue, May 8, 2012 at 11:37 AM, Carla F. Griggio
<[hidden email]> wrote:
> 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 :)

what about some screenshots to help us get a feeling of what you did?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

classDiagramPirates.png (99K) Download Attachment

Stéphane Ducasse

Re: smallUML news: towards autogenerated diagrams

In reply to this post by Carla F. Griggio

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.
>
>

abergel

Re: smallUML news: towards autogenerated diagrams

In reply to this post by Carla F. Griggio

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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Carla F. Griggio

Re: smallUML news: towards autogenerated diagrams

Hi!

Stef, I use a block because the idea is to get a diagram of a "scenario". This is a first approach, but my goal is to generate the diagrams from test runs. Of course this will be able to be used in different ways, but for now I'd like to get diagrams of delimited scenarios, for example, a diagram of a use case, instead of one big diagram of a whole project. I think it can help communicate better how the use cases of a project are implemented.

The model behind the diagrams it's still the same I designed during GSoC 2010, I attach a class diagram showing the structure of a diagram.

If you inspect this, you'll be able to see the objects representing class boxes and relationships:

[|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

Alex, try this new version:

Gofer new

squeaksource: 'smallUML';

package: 'ConfigurationOfSmallUML';

load.

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

I added a few more things. I'm experimenting with a new way of organizing diagrams. Now if you open a Diagram Browser, the diagrams will be listed by category, so we can organize diagrams by categories.

DiagramsHolder openDiagramBrowser

If you generate a diagram from a block and open a quick view like this:

[|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

after you accomodate the diagram nodes you can save it into a category by doing right click on the diagram -> Save for category.... There you give a name to the diagram, and type the category it's related to, and your diagram will be saved as a method in an extension category inside the class DiagramsHolder.

If you browse DiagramsHolder, you'll see all the diagrams as methods. I think that's cool because diagrams can be versioned as code :)

Cheers!

Carla

On Fri, May 11, 2012 at 11:08 AM, Alexandre Bergel <[hidden email]> wrote:

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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Diagrams Model.png (130K) Download Attachment