Modelling tools for ST or Dolphin?

Hi all,

Does anybody know of modeling tools that could be used with Dolphin, or
ST in general?

So far I just go ahead and code, no design, planning or modeling. I do
get my code to work eventually, but I have a hell of a time to figure
out what I've done over the course of a couple of weeks.

So basically I'd like to become a bit more methodical.

Günther

Günther,

> Does anybody know of modeling tools that could be used with Dolphin, or
> ST in general?

CRC cards are generally thought to be a good match with The Smalltalk Way.  You
may find it worth experimenting with them (use actual physical pieces of paper
or card, don't be tempted to put it on the computer).  Google will find more.

Other people like to scrawl UML diagrams on the backs of envelopes, beer mats,
or napkins.  Personally I find that approach over-formal ;-)


> So far I just go ahead and code, no design, planning or modeling. I do
> get my code to work eventually, but I have a hell of a time to figure
> out what I've done over the course of a couple of weeks.

The book "Object Design" by Wirfs-Brock and Keane might interest you.  But find
a copy you can browse before buying, you might find it overly abstract (it's
not Smalltalk-specific, in fact it is completely language-agnostic -- it has
plenty of examples, but no code at all).  It's also a tad too prescriptive for
my taste, but I do think their way of thinking about designs (in terms of roles
and responsibilities) is very sound.

You might also want to read about so-called "test driven development" -- which
is actually (IMO) more like "design expressed as xxUnit code"[*].

I'm not /recommending/ any of the above approaches (I use none of them myself),
but one or another may suit you.

    -- chris

[*] I think the word "test" in the methodology name is misleading.  It could
even fool the naive into thinking "well, we wrote the tests first, so once the
software is finished we don't need to do any more testing" -- which would be
absurd.

Günther Schmidt wrote:
> Does anybody know of modeling tools that could be used with Dolphin, or
> ST in general?
>...
> So basically I'd like to become a bit more methodical.
>
Hello Gunther,
 Pick up a used copy of 'Smalltalk in Brief' by Lambert. It was for
theST/V dialect, which is extant as STExpress with WindowBuilder, as a
free download. It used basic 'collaboration' diagrams and matching
Smalltalk code, emphasising modeling before GUI development. The big
project in the book is about check / banking accounts modeling and GUI
development, similar to Dolphin's Personal Money tutorial and VW old
checking account tutorial. The diagrams were simple; rectangles, one
headed arrows and dashes and dashed rectangles. The annotations were
numbered in sequence of code execution (message calling) matching what
one might anticipate writing.

Below is a sample from the book, just before tackling the banking
system project :
======================
The Software Development Life Cycle

1. Analysis.  In this phase, examine the system's requirements and
determine the classes needed. Draw a diagram, called an object model,
that shows the objects and the relationships between them.

2. Design.  In this phase, determine how the classes communicate.

3. Implementation.  During implementation, translate the design into
Smalltalk code.

4. Testing.  Not a separate phase, but done continuously, by unit
testing and walk-throughs. To the extent possible, testing of classes
are done in isolation before being integrated into the larger system.
Integration is done on a piecemeal fashion.

User Requirements - a Banking System

Verbal description - A bank offers three kinds of accounts: a checking
account, a savings account and a charge (credit card) account. These
accounts are accessed by customer name and by account number. In
addition, the software supports the following functions:

1. Add a customer.
2. Modify a customer (change of address, etc.).
3. Delete a customer.
4. Add a savings account.
5. Add a checking account.
6. Add a charge account.
7. Delete an account.
8. Deposit money.
9. Withdraw money.
10.  Apply interest and charges at the end of the month.
 Attributes of Instances

Individual accounts have the following attributes (instance variables):

Savings Account

· account number
· balance
· minimum balance during the month

Checking Account

· account number
· balance
· number of checks that bounce because of insufficient funds, called
bad checks
· number of checks written below the free check cut off (customers can
write checks for free if they maintain a minimum balance)

Charge Account

· account number
· balance
· previous month's balance
· payments received this month
 Attributes of Classes

In addition to attributes of individual accounts, the following
attributes are shared by all accounts of the same type (class
variables):

Savings Account

· interest rate

Checking Account

· bad check charge
· free check cutoff
· charge per check

Charge Account

· credit limit
· finance charge rate
 Analysis Phase


1. Layout the user interface.

2. List the classes needed by the model. Underline all the NOUNS.
Delete synonyms and what are left will be CLASSES and their ATTRIBUTES.
VERBS may be candidates for messages.

3. Determine the relationships between the classes and present this
information in a diagram called an Object Model.

4. Make an initial attempt to determine where the new classes will fit
into the existing Class Hierarchy.

============================
The book goes on to develop the classes and working code
Hope this helps
ACG