Sophie,

Yes, yes. I am currently coding with roles as pragmas as in this method:
    /stepArrows
        <Role: #ArrowtrainHead>
        ArrowtrainHead isFinished
        ifTrue:
            [...
            currentState := #FLASHSTAR]
        ifFalse:
            [ArrowtrainHead smallStep]
/where inline code binds role names to application objects through a 
collaboration dictionary that lives on the stack. (Through a small 
extension of the compiler).

My next step is to code the methods as Traits, thereby further loosening 
the binding between role and object/class. I didn't mention the 
non-class structures earlier because their usage is somewhat immature 
for squeak-like programs. All the behavior part of UML 2.x should be 
worth looking at for modeling Squeak processes.

Cheers
--Trygve

On 19.02.2008 16:04, itsme213 wrote:
> "Trygve Reenskaug" <trygver at ifi.uio.no> wrote in message
>   
>> 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).
>>     
>
> Like a collaboration? Could one use:
>     A>>m1
>         <collab: #c1 role: #r1>
>         <collab: #c2 role: #r1>
>     A>>m2
>         <collab: #c2 role: #r2>
>     B>>m3
>         <collab: #c1 role: #r3>
>
> Could be done in Traits as well.
>
> Thanks for sharing your insights. I was expecting the newer (non-class) 
> structure diagrams to be on your list :-)
>
> 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/10751ae3/attachment.htm