UML Modelling?

How do you make a UML model for smalltalk code?

--
David Zmick
/dz0004455\

Do you just want examples or a tool?

UML has lots of diagrams. Are you looking for static class diagrams?
Object interaction diagrams? Deployment diagrams? etc.

On Wed, Feb 13, 2008 at 7:42 PM, David Zmick <[hidden email]> wrote:
> How do you make a UML model for smalltalk code?
>
> --
> David Zmick
> /dz0004455\
>
>
>

On 14.02.2008 02:42, David Zmick wrote:

How do you make a UML model for smalltalk code?

--
David Zmick

UML is a modeling language and doesn't care about code. So you can model Smalltalk or Java programs or whatever. UML has static typing, and a large part of it collapses if you ignore type.

UML is a large language designed to cater for a multitude of requirements. The intention is that you select the parts you need and disregard the rest (which will be the larger part). The key for you is to decide why you want to model your program. This boils boils down to deciding why you are not satisfied by just writing and reading the code.

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.

There are many UML tools. I have only tried one or two and found them extremely heavy to use. I have found they are generally  not worth the added complexity and hassle.  (I recently tried to get an understanding of Traits by drawing its class diagram. It did not help me at all.)

Many UML tools provide code generation. The ones I have seen were very incomplete even for Java. For Smalltalk, you would have to provide the translation algorithms yourself.

I suggest you select a few UML diagram types and use them for informal (back-of-envelope) design purposes. Any other use would be contrary to the spirit of Smalltalk.

Cheers
--Trygve

Hello David,

For class diagrams you could use the Connector package.

http://squeak.pbwiki.com/Connector%20Tutorial

Regards, Has.

On 2/14/08, David Zmick <[hidden email]> wrote:
> How do you make a UML model for smalltalk code?
>
> --
> David Zmick
> /dz0004455\
>
>
>

"Trygve Reenskaug" <[hidden email]> 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

 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" [hidden email] 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" <[hidden email]> 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

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" [hidden email] 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" <[hidden email]> 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

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" [hidden email] 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 





  

"itsme213" <[hidden email]> 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

"Andreas Raab" <[hidden email]> wrote in message

> Actually calling it "rename" is wrong. It's an "alias".

Thanks for the explanation, you are right.

I am actually interested in the case where the
    #bar
is not implemented by the trait (hence is a required method), and I want the
self call to #bar to instead make a self-call to #baz (would "renamed" be
the right word for that?) so:

TSample>>foo
    ^ self bar

now behaves like

TSample'>>foo
    ^ self baz

I don't think traits do that. I believe it would be a useful capability.

Thanks,

Sophie

On 19.02.2008 21:40, itsme213 wrote:

"itsme213" [hidden email] 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" <[hidden email]> wrote in message

Even with serialized / sequential method calls, you might still want to
handle an object performing some (complete) behavior as
programmer-in-project-1, then as programmer-in-project-2, then back to
project 1, etc. Alternately you can just handle those cases as 2-separate
"programmer" objects composed within one "person" object (if that fits
within your overall role-vs-object thinking), but that might slightly dilute
the role-vs-object distinction.

Just sharing my thoughts, though this is a bit OT from UML modeling..

- Sophie