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."

Comments

Impedence mismatches

[bigsteve@dstc]

Grady Booch is right about the mismatch between relational databases and OOP modelling. But in reality, this mirrors a more fundamental mismatch between databases (in general) and programming languages.

To put it simply, data is handled differently by the storage system in an executing program. Typically we find:

• Data is represented differently; i.e. the basic type systems are different.
• Data is organized differently; e.g. tables and indexes versus lists, hash tables, etc.
• Data accesses and update models are different; e.g. queries and transactions versus ad hoc programmed searches and synchronization.
• Database access and non-database code is typically written in different languages, often in the same "program".

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.

Re:Impedence mismatches

[randomjotter]

Of course both are different. They are meant for different things! The question to ask is if they do what they intend to do and does database being different has affected OOP anyway. There are abstraction layers available in any platform for you to work oblivious of the underlying data sources( what ever that might be from databases to text files). Does that really affect me at the programming level.Donot think so.

Re:Impedence mismatches

[bigsteve@dstc]

Of course both are different. They are meant for different things!

Fundamentally, DBMS and programming languages are both meant to do the same thing; i.e. allow you to build "systems". While most people make a clear distinction between DBMS and (and file systems) which handle persistent data and Programming languages which handle in-memory data, this does not need to be so. There is no fundamental law of IT that makes this so. Indeed, the fact that there are Orthogonally Persistent PLs that work clearly demonstrates this.

There are abstraction layers available in any platform for you to work oblivious of the underlying data sources( what ever that might be from databases to text files). Does that really affect me at the programming level. Do not think so.

Actually, the DB (or FS) versus PL affects you at a pretty fundamental level, because your programs are designed to use different abstractions to deal with persistent and non-persistent data ... or persistent and non-persistent incarnations of the same data.

The fundamental idea of an OPPL is that you are not forced to deal with two kinds of data ... anywhere. Persistence just happens, without you (the programmer) having to worry about it.

testing mentioned once, rational robot not at all

[stanwirth]

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.

Uh, anyhow...

[SN74S181]

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.

Re:Uh, anyhow...

[You're All Wrong]

Woo woo!

I've worked on large projects that used an OO language, and an OO design, where there were _11_ different abstract "linked list" base classes (huge project started in 1992 before the STL was around, but still being worked on 11 years later in its maintanance phase).

If that's code re-use, then my arsehole's a lilly.

However, I don't think you sharpenned your claws quite enough, as you didn't attack
"Grady Booch is one of the Big Names in Software Engineering"

to which I think you should have said something like:
"Pah, Grady Booch is a slimy little bugger who'll change his view on what's best for everyone every couple of years such that he can bring out a new book with a new 'methodology', with a new graphical representation that's different enough from what has come before that you are _obliged_ to shell out another couple of hundred dollars to buy the accompanying piece of software to permit you to use that methodology." or something. Don't feel you have to hold back - this is Slashdot!

YAW.

isn't UML supposed to be a language?

[kruntiform]

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?

Re:isn't UML supposed to be a language?

[jorleif]

UML is mostly meant to be a standard notation to aid communication between people. UML is not merely a design language, but also an analysis language that can be used to model the problem domain. To do this kind of analysis in a programming language would hardly be a good idea

UML is fundamentally OO so impedance matches between UML and OO-languages should not become very big. It's a recommended practice to do design models in UML using the constraints of the implementation language. For instance UML has no problem with multiple inheritance, but Java does not support it, so systems developed in Java should not be modeled using multiple inheritance.

I agree with you that his argument about languages is rubbish, especially as he describes languages that are fundamentally so similar, that one would be best off picking the one with the best libraries for the task. This whole notion that the programming language should protect people from their own bad programming is also very stupid (which Booch also said). Bad programming is always possible. Of course I'd rather have Java created by monkeys than C created by monkeys, but neither is going to be very good. I'm not certain I'd prefer Java by geniuses over C from geniuses.

Back to the future?

[Bazzargh]

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

Re:Back to the future?

[derubergeek]

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

Oh, come on. Give Grady a break. You can't expect him to keep himself fed if he actually did produce something with any longevity. Gotta keep those book sales, Rational tools, and lecture/training circuits a rollin'...