Computer Science Education

johnhall johnhall@isomedia.com
Tue, 28 Jan 2003 08:57:05 -0800


> From: On Behalf Of Russell Turpin


> One diagramming technique I would
> recommend is statecharts. They are a
> generalization of state diagrams, and if
> I recall correctly, they are now
> sanctioned as a part of UML.

One of my problems is that there is no technique I always use (when I
use a technique other than 'start typing').

I covered state charts in my OO class with some hand waving about how
obvious they were.  I used an example where you are doing a game and the
behavior of the Troll depends on his STATE.

I dismiss state charts until I run into situations where it is
'obvious'.

Part of the issue is I've always been on small teams.  A lot of material
gets conveyed verbally or with quick and informal pictures on a dry
erase board.  Not needing to communicate with 100 people in 20 different
states, I've never had to capture my ideas as stand alone documents.

 
> BTW, one of the drawbacks to UML is that
> it lacks a rigorous semantics, in contrast
> to other techniques such as Shlaer-Mellor.
> This is a real drawback for teaching,
> because there isn't really a good answer
> to the question: "what does this model
> MEAN?"

I focus on 'basic UML' and try to get the kids to learn that these are
TOOLS.  Use the tools, don't let the tools use you.  The purpose is
communication, not getting all the pictures just right.  One UML book
listed a 'top 10' Use case error as arguing for 6 months on whether to
use "include" or "extend".

> It's pretty
> neat when your OOA models ARE the software,

It has always been a neat idea.  It just seems that getting it to work
is harder than it sounds.