My 2 c - Sophie ,

The most important phenomena occur in the space between the objects, so 
I don't think method annotations would help (since they apply to one 
method at the time).

The UML Sequence Diagram is often useful. It would be nice if it could 
become either the program itself or a constraint. I have used it to 
visualize the stack at a given point in an execution. It got too large 
to be useful in the examples I tried, so I stick to the textual 
version.  You can find the very simple set of textual methods as part of 
the BabySRE package. (Smalltalk Reverse Engineering)

The methods are Object>traceRM:, stackSnapshotBrowseOnce: levelCount, 
and others that can be found at my Monticello repository
    http://heim.ifi.uio.no/~trygver/babymc/
package
    BabySRE
version e.g.,
    BabySRE-TRee.39.mcz
Browse to find Object extensions->*BabySRE-TraceStack

Cheers --Trygve



On 14.02.2008 15:08, itsme213 wrote:
> "Trygve Reenskaug" <trygver at ifi.uio.no> wrote
>
>   
>> IMO Smalltalk (like Java) lacks facilities for describing systems and
>> particularly system behavior. UML 2.x has very powerful facilities for
>> such modeling and could prove useful both for design and for 
>> documentation.
>>     
>
> Which parts in 2.x do you find best for this?
>
> Have you considered whether Squeak method annotations might bridge some of 
> the gap?
>
> MyClass>>foo
>   <annotation:#a with: #b>
>
>   
>> Any other use would be contrary to
>> the spirit of Smalltalk.
>>     
>
> Squeak class hierarchy to UML diagram is easy; attributes and associations 
> are hard. To work typed UML <-> typeless Smalltalk code, you would need 
> either additional type annotations (e.g. pragmas on read-accessors) or type 
> inference (e.g. RoelTyper). Other UML diagrams might need additional 
> annotations.
>
> There is a Connectors-based package languishing somewhere that lets you draw 
> some rudimentary UML in squeak itself. Dandelion, also languishing, does 
> some Squeak code analysis and exports XMI
> http://www.mars.dti.ne.jp/~umejava/smalltalk/stClasses/dandelion/index.html
> http://www.mars.dti.ne.jp/~umejava/images/MagicDrawDandelion1.jpg
>
> Dynamically figuring things out from the instance-level would be a different 
> matter, specially if the tool was able to summarize certain information. 
> There is a nice ClassDiagrammer available that reconstructs a class diagram 
> from a set of instances, with a little work it could be very useful. A 
> sequence diagram generated from actual trace of method sends could also be 
> very useful. If you prefer to diagram first, then some of these diagrams 
> could conceivably become inputs to tests.
>
> My 2 c - Sophie
>
>
>
>
>
>   

-- 

Trygve Reenskaug       mailto: trygver at ifi.uio.no

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080219/c84ffb1e/attachment.htm