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

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

itsme213 wrote:

Traits use unimplemented self-calls as "required methods" to (among other things) access such state. However, you cannot parameterize these required methods (you can rename provided methods, but not required methods which would need some kind of automatic code generation/re-writing of intermediate traits).

Actually calling it "rename" is wrong. It's an "alias". If you're wondering what the difference is, try this: Define a trait which has two methods like

Trait named: #TSample

TSample>>foo ^self bar

TSample>>bar ^42

and then use it via, e.g.,

Object subclass: #TSampleTest uses: TSample @ {#mumble->#bar}

At this point, I'd expect either of two things to happen for a "rename": Preferredly, foo should call #mumble instead of #bar (since we renamed #bar in the trait) or alternatively the class should simply have two methods #foo and #bar.

What you get instead (and why it's not a "rename" but an "alias" instead) is three methods: #foo, #bar, and #mumble with #mumble being simply a copy of #bar. In other words, you have just created an alias for #bar under the name of #mumble.

Cheers, - Andreas

My collaboration is a name space for roles. An object can play different roles in different collaborations, but I cannot have the same role in different collaborations since the role is an attribute of the collaboration. Roles in different collaborations can thus have the same name without conflict.

Anther question is the name space for traits/methods, and there may be potential conflicts here. I am trying to get some kind of Browser with Traits, hoping that experiments will clarify what I am talking about.

Your example, "I am a Programmer in project p1, and also in project p2. " is unclear to me because I cannot see how it relates to system behavior. It could mean that p1 and p2 are instances of the same class and I do not see a problem. Alternatively, p1 and p2 could be instances of different classes with different features. In that case, the example sounds to me like part of a conceptual schema; i.e., a description of system state.

I use different paradigms for coding system state and system behavior. I code system state as an ensemble of classes with their attributes and associations. I code system behavior as a collaboration with its associated methods for each system operation (use case). Traits seem promising for coding system behavior as stateless methods within a collaboration.

Cheers --Trygve

On 19.02.2008 19:29, itsme213 wrote:

"Trygve Reenskaug" trygver@ifi.uio.no wrote in message

btw, I get various errors loading BabySRE in Squeak 3.9.

...

My next step is to code the methods as Traits, thereby further loosening the binding between role and object/class.

I wonder how far Traits can help. An object can play the same role in two different collaborations e.g. I am a Programmer in project p1, and also in project p2. One would like to apply the same Programmer trait twice, with the option of having separate (class-based) state for each of p1 and p2. I don't think this is possible with Traits.

Traits use unimplemented self-calls as "required methods" to (among other things) access such state. However, you cannot parameterize these required methods (you can rename provided methods, but not required methods which would need some kind of automatic code generation/re-writing of intermediate traits).

I am hoping to get Damien's or Stephane's insights on this. http://www.nabble.com/A-Traits-question-td15484148.html

Do you think you will hit this limitation? Or does your intended usage avoid this issue?

Thanks!

Sophie

On 19.02.2008 21:40, itsme213 wrote:

"itsme213" itsme213@hotmail.com wrote in message

...

An object can play the same role in two different collaborations

Bad wording on my part, apologies. I meant "in two different instances of the same collaboration (type)"

collaboration ProjectCollab role Programmer ... role Customer ... etc.

So there can be many ProjectCollabs going on at a time (one for each project), and each one has its Customer, Programmer, etc. And I can play the Programmer role in more than one of those.

Is that consistent with your thinking?

• Sophie

YES. But I am simplifying my work by considering sequential processing only. Multiple threads or processes is for the future. Egil Andersen worked with role modeling and multiprocessing in his thesis. He developed a variant of Harel charts to handle them, but it was definitely non-trivial and full of pitfalls.

--Trygve

--

Trygve Reenskaug mailto: trygver@ifi.uio.no

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

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

Norway