Show me your flowchart and conceal your tables and I shall continue to be mystified. Show me your tables and I won't usually need your flowchart, it'll be obvious.
I think substituting 'messages' for 'tables' preserves the meaning while bringing it forward into what seems to becoming a service-driven era. Guy Steele did something similar a few years ago, except specifying object interfaces instead. Too much coupling, messages work better
Posted from cwinters.com; read original
Errrm, I think not. (Score:2)
"Tables" is more like "data structures". Messages are APIs, that is, "flow charts".
Re: (Score:2)
Maybe I'm misinterpreting, but I read the quote as saying that with only flowcharts and no data you'd be hard pressed to figure out what an application actually does. With messages -- including the message name and the data accompanying a message -- I think you can get a very clear picture of what an application does.
It doesn't apply in all cases, but IME it's been more useful in the applications I've been working on for the last five years, particularly when you consider that people can hide crappy datab