There's even an explanation of "object-oriented" data flow diagrams, just like EdYourdon? taught you to do. This was the required text for my MSc OO course, and the lecturer wisely reccommended that we staple those pages together without ever reading them.
Ever wonder where the incomprehensible, unjustifiable and inexplicable separation between "attributes" and "operations" on UML class diagrams came from? It came from here. Back when MartinFowler was touring just after the great unification (and promoting UmlDistilled) he rightly encouraged people to read the excellent DesigningObjectSystems, wherein Cook and Daniels reveal, through the mechanism of "perspectives", just when this distinction between operations and values makes sense, and where it doesn't. It mostly doesn't.
Ah, but the movement of a model from one perspective to another is a transfomation! And OMT (this is the OMT book) is all about seamlessness. Turning your analysis of the situation into a design, why that's just a matter of adding more, more detailed information. Doesn't need any change in even the style of presentation, never mind in modeling vocabulary and semantics. And from design to implementation? Just pour on the detail. This is music in the CASE tool vendors' ears, and poison in everyone else's. -- KeithBraithwaite