Slashdot Mirror
Grady Booch On Software Engineering
aebrain writes "Grady Booch is one of the Big Names in Software Engineering. If you use OOP or UML you're making use of his work. There's an interview with him on .NET that's interesting reading ('Language was once Key - Now it's Design'). Lots about the impedence mismatch between SQL and OOP, what the future holds re .NET and Java, and when UML modelling isn't appropriate."
I read that as Brady Bunch :(
I probably need to get more sleep.
that would be impedance mismatch.
See impedance
Thank you Merriam-Webster.
Code poet, espresso fiend, starter upper.
To put it simply, data is handled differently by the storage system in an executing program. Typically we find:
Over that last (at least) 20 years, there have been attempts to remove the database / proogram impedence mismatch. The most radical approach is Orthogonal Persistence. This aims to treat all data the same, irrespective of its lifetime. Data that needs to persist is made to persist without the programmer doing ANYTHING about it.
Classical examples of Orthogonal Persistence are the PS-Algol and Napier-88 programming languages. A notable (relatively) recent example was Sun Research Labs' Forest project which added OP support to Java. Unfortunately, the Forest project was shut down. My guess is that it conflicted with Sun's vision for mainstream Java. Sad.
This is the most important paragraph in the article:
The healthiest organizations we encounter do development iteratively and incrementally; testing continuously. They have good configuration management policies. A lot of organizations still don't have this. An astounding number of development teams don't use any configuration management tools. This reflects the fact that a lot of software development teams are going about it in an ad-hoc fashion. That's a problem of process. And until they get their process right no tool you throw at them will add value.
Read that 10 times. I've seen it over and over. Happens all the time. I didn't know whether to laugh or cry. I wish he'd mentioned Rational Robot at least once, and the importance of test harnesses in general. gcc and g++ would never have gotten where they are today without dejaGNU, for example.
His comments on the mismatch between relational data and OO data is quite true -- Zope, for example(which is, underneath it all, an OODBMS) just falls over when you start loading it up with 10 GB or so, which is why it's recommended to put an RDB under it for relational data, and access to a chrooted jailed filesystem for big data stored as flat files. It would have been reasonable for him to mention, however, that these issues are addressed in spades by tools such as Oracle 9iAS connected to an Oracle 9i DB, and IBM Websphere connected to a DB2 UDB in the real world. In terms of functionality, these are are the "enterprise-ready" tools that sit in the same space as Zope and PostGreSQL.
I was also surprised that, in his discussion of bringing relational and OO data to the end user he didn't mention Data Warehousing, OLAP (Online Analytical Processing), Metadata Management tools, Multidimensional database technologies, Business Intelligence tools and such as Cognos, Oracle SQL_OLAP and BI_Beans, Coglin Mills, Datastage, etc etc etc. But then, it was already 10 pages long, and the .NO^hET Magazine editors might
not have been able to find the space for the balance of that
discussion.
I hate to be an Assembly Language redneck about this but: Object Oriented doo daa doo is seeming more and more like software-for-the-sake-of-software-developers. A lot of hand waving about 'code reuse' goes on, and a lot of talk about 'well written code' but in the end there are two areas of software development that look bright in the future:
1. Tightly written embedded code.
2. Code written by people 'close to the site where it will be used', i.e. code for point-of-sale written by people specialized in the POS biz.
As software development tools become more and more powerful, fewer and fewer guru-level experts are needed. It's far more valueable to the development process to involve the people who actually do the real-world tasks that the software will assist in accomplishing. And those are NOT going to be people who plonked down their $70 for the latest Gooch/Rational Software propaganda hype-hardbacks.
The buzz surrounding 'Object-Oriented' and similar catch phraseology seems like a job program for specialists with no experience outside of software engineering, and a panacea for academics wanting to weave fancy webs.
Well, enough said.
Language isn't so important, but Universal Modelling Language is. That seems a bit contradictory to me. Okay, so now we have a design langauge and an implementation language both describing the exact same software at the same time. It sounds like there's a lot of potential for impedance mismatches between those two right there.
He backs up his assertion that programming languages aren't important by saying there is lots of good software written in different languages. But there is lots of good software written without UML. In fact most good software would fall under that heading. Does that mean UML is not important?
Stupid job ads, weird spam, occasional insight at
Its interesting that Booch talks about an 'executable, testable UML 2.0', given the history of his own methodology. Prior to UML, the Booch, Rumbaugh, and Jacobsen advocated design by elaboration. This meant you continually add artifacts to your design and code until you get to a running system. The 'tools' did nothing but book-keeping for you. They unified their approaches into the UML.
;)
Standing on the other side was the Shlaer-Mellor method, which advocated design by translation (also called recursive design). In this methodology, you diagram different 'domains' and write code generators to eventually produce executable code directly from the model. CASE tools provide assistance in actually producing software (now there's a novel idea).
UML put a lot more emphasis in 'round tripping' in CASE tools, because you edited artifacts that were derived 'in your head' and often failed to match the original model (would you consider editing java bytecode, or asm files?), culminating in the excellent TogetherJ. In Shlaer-Mellor round-tripping didn't matter - you worked on the model and the translators, never on the end code directly (you modify the translator to alter generated code).
I remember back in the day, all the Booch advocates denigrating Shlaer-Mellor, saying it would never work, but here we are, with Booch telling us he's doing executable UML...ah well, at least the methodology wars are over - looks like the tool & book vendors won
- Baz
You were doing so well, then you had to throw Flamebait into the mix. Sigh.
Hardly flamebait. Flamebait would be ".net is unchristian". .no^het is just an expression of contempt for yet-another-m$-proprietary technology, like m$ is an expression of contempt for the profit-motive-driven microsoft corporation.
Funny you should mention that. I have a tape of one of Grady's lectures where he said: Not that it has anything to do with
Sig ?
The biggest problem I see with "executable UML" is that in order to make it detailed enough to be executable, you have to insert tons of detail into the UML model. There is a point where it is easier for some (perhaps most) developers to work with those details as code instead of as a sprawling set of diagrams.
IOW, just because you can program entirely with diagrams, does not necessarily mean you should.
I will agree that some people prefer diagram-based programming, and a tool called LabView has been doing this for years. It tends to match electronic circuit diagrams, so e. engineers grok it fairly quickly. Whether it makes them more productive than those who master code is hard to say.
Perhaps some shops that can hire people who think alike can go diagrams galore, put I don't think it will fly everywhere. Some linguistical people probably think in code no matter what.
Table-ized A.I.
All pictogram-based programming languages died horrible deaths - as they should. There is a good reason why human beings developed a written language - because you can communicate your ideas much more concisely and effectively with written words than ambiguous pictures. Speaking of pictogram-based coding, using Rational Rose is a nightmare of modal nested dialog boxes. Who designed that user interface? Oh, I see, the "experts" on design - nevermind.
To find at:
IBM-Developerworks
Keep open minded - but not that open your brain falls out...
Lots of useful content, then a bit of childish name calling to spoil the effect
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
When people talk about .NET , J2EE in the context of web development, how come XPCOM is missed out. It might not be a complete framework as .NET or J2EE are, but with C++, the mozilla hackers have managed to make a framework, which is faster and is also based on C++.
How come it is missed out ?