Bruce Eckel on Object Design

If you're into Software Engineering (like I am), you'll be interested in reading Bruce Eckel's blog post on Object Design. He writes (also) about how people confuse abstraction layers, and how the UML doesn't help in this field.
I also wrote a comment in the thread, which I'll duplicate here (but first read the original post):

I'm a Software Engineering student - graduating in a few weeks. My final project is a Statechart code generator + simulator for a high-tech company.
Interestingly, I had two problems with UML while developing the software:

1. The designer of the statecharts I had to generate code from uses UML it in a very abstract manner. For example, in actions he doesn't call real functions - he just puts some text that will mean something to someone. That's because this is the company's first attempt at code generation - and the designer "knows" that a human will read the charts and translate them into code (and not a computer).

2. When, in the middle of the year, I had to prepare UML diagrams to document my own software, I found it impossible: most work (code generation) was done in XSLT, which is not OO - so I found no matching UML diagram. Instead, I came up with a DFD that shows what my software does. Since DFDs are not part of the UML, and because I found no open-source DFD diagramming tool, I had to use... PowerPoint!

For fixing the first problem, I wish UML tools had "design modes", something based on Fowler's UML Mode (http://martinfowler.com/bliki/UmlMode.html) referred-to earlier in this thread. That is, in the "sketch" mode, the tool will hide those detailed-design features of the UML (like composition/aggregation). When running in "programming" mode, users will be able to add these details to the model. Later, when the high-level designer edits the model again, those features will be hidden - but will remain in the model. I realize that doing this correctly is not trivial - it's in my wish-list nevertheless.

The second problem is different. UML is for OOAD, not procedural/functional design. But there are still projects that use the older methods. What diagrams should they use? In my college, they teach UML thoroughly, but say next to nothing about the other options - as if one should never develop non-OO software.

________________________
Tag: Software