Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Technology

Grady Booch On Software Engineering 52

Posted by timothy from the spoken-word dept.
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."
This discussion has been archived. No new comments can be posted.

Grady Booch On Software Engineering More

Grady Booch On Software Engineering

Comments Filter:
  • that would be impedance mismatch.

    See impedance [m-w.com]

    Thank you Merriam-Webster.

  • Impedence mismatches (Score:5, Interesting)

    by bigsteve@dstc ( 140392 ) on Monday May 12, 2003 @10:25PM (#5942056)
    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.

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

        • Your description makes it sound like databases are *only* for persistence. This seems common among the OO crowd. IMO this is because OO fans would rather reinvent database-like fatures in app code rather than let the database handle it (per my other message). This is poor "reuse" IMO. Here are things databases can take care of:

          1. Persistence
          2. Query languages or query ability
          3. Noun Modeling
          4. State management
          5. Concurrency - Multi-user contention management (locks, transactions, rollbacks, etc.)
          6. Backup
          • Your description makes it sound like databases are *only* for persistence.

            That was not my intention. Classical DBMS do a lot more besides simply making data persist. But most of the things you list as things that DBMS do could also be done in a fully fledged Orthogonally Persistent Programming Language / environment. For example:

            • Assuming that a query language and query optimizer is required, these could be implemented as a suite of library code that makes use of reflection.
            • Constraints and data v
            • could also be done in a fully fledged Orthogonally Persistent Programming Language / environment.

              How does an OPPL differ from a "database" then?
              • How does an OPPL differ from a "database" then?

                It differs in that it has all the functionality / usability of a conventional programming language, including all of the data types / constructors and all of the control constructs you'd expect to see there. Think of (say) a dialect of Java in which the way you accessed / updated data was completely independent of its persistency.

                BTW, I didn't mention Java by accident. There are two existing implementations of Java with support for OP; i.e. 'pJama' and 'K

                • It differs in that it has all the functionality / usability of a conventional programming language,

                  Which language? Application language? A language like Oracle's PL/SQL? If in Java, why is Java better than a relational language (like SQL, although SQL is not the best IMO)?

                  Think of (say) a dialect of Java in which the way you accessed / updated data was completely independent of its persistency.

                  I am not sure what you mean by this. Databases are for more than just persistence. If you are only using
                  • Which language? Application language? A language like Oracle's PL/SQL? If in Java, why is Java better than a relational language (like SQL, although SQL is not the best IMO)?

                    Would you write a compiler or a scientific application in PL/SQL? Why not?

                    Think of (say) a dialect of Java in which the way you accessed / updated data was completely independent of its persistency.

                    I am not sure what you mean by this.

                    In a typical OPPL (e.g. PSAlgol, Napier88, pJama), the only thing that distingusishes persi

                    • Would you write a compiler or a scientific application in PL/SQL? Why not?

                      I don't know. I don't write compilers and scientific applications. I thought those all went to India, or soon will, anyhow.

                      To make any object persist, you simply make it reachable.

                      What if a non-OOP language/tool needs access, especially query access, to the data?

                      I've already pointed out that most of what a conventional DBMS does is also doable by the OPPL itself

                      Doable, and do well at are two different things.

                      One rea

                    • To make any object persist, you simply make it reachable.

                      What if a non-OOP language/tool needs access, especially query access, to the data?

                      There are lots of answers to that:

                      • If your OPPL is an extension of a general purpose programming language (e.g. Java), why do you need to use another language? (OK, there are cases, but this is the exception, not the rule. In the same way that it is exception to have to mix C / C++ with Java.)
                      • The OPPL could support calls to/from embedded libraries written in
                    • If your OPPL is an extension of a general purpose programming language (e.g. Java), why do you need to use another language?

                      Oh boy. Java forever. Even if something better is found (which is not hard to do IMO).

                      So in short, you eventually turn your OOPL application into a database server and/or a network server. That is about as logical as using a car for a tool shed.

    • Re:Impedence mismatches (Score:1, Insightful)

      by Anonymous Coward
      There's less of an "impedance mismatch" in languages where OO is real OO and doesn't suck - e.g. Common Lisp + UnCommonSQL is pretty impressive.
    • I agree there is an "impedence mismatch". There are fundimental base philosophical differences between relational tables and objects that have resisted solutions.

      Relational fans (like me) tend to put and keep the "noun model" in the database, while OO fans want to put it in application code (sometimes through duplication of what is in the database. Such duplication is to be avoided IMO. It makes for too many change-points.) IMO the noun model is better in the database so that sharing info with other langua
      • Relational tables impose certain constraints on data that OO does not. This might seem limiting at first, but it also allows the power of "relational algebra", which OO does not have a usable equivalent of yet.

        I'd say that languages like OCL and OQL are OO's moral equivalent to a language for relational algebra. But there is still an impedence mismatch between OO query languages (e.g. OCL/OQL) on the one hand and OO programming languages (e.g. Java) on the other. What is needed is a language / environ

        • I'd say that languages like OCL and OQL are OO's moral equivalent to a language for relational algebra.

          OQL is too similar to the CODYSAL (spelling?) query languages of the pre-relational era. It has not caught for similar reasons.

          What is needed is a language / environment that supports both paradigms within a single syntactic framework and type system/value domain.

          Easier said than done. Further, if you have a strong type system, what about using it with dynamically or type-free languages?
    • You're not Steve Blackburn are you? If you are, I thought you were at ANU/Amherst...

      In any case, I spent a couple of summers working for the Persistant Java team at Glasgow. You can still find info on the implementation at:

      PJama [sunlabs.com].

  • testing mentioned once, rational robot not at all (Score:5, Interesting)

    by stanwirth ( 621074 ) on Monday May 12, 2003 @10:44PM (#5942136)

    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... (Score:4, Interesting)

    by SN74S181 ( 581549 ) on Monday May 12, 2003 @10:58PM (#5942182)
    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.
    • 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
      • 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).

        Doesn't your comment answer itself? If STL *had* been around, or *gasp* Java, then every competent developer would know there is a single solution that fits their needs. Without even so much as a common standard, there would only be one linked

    • Re:Uh, anyhow... (Score:2, Insightful)

      by Anonymous Coward
      That sounds alot like something certain members of the craftwork industry might have said around the time the power loom was invented.
      • The power loom industry wasn't producing 'power looms for the sake of power looms'. And they weren't selling book after expensive book hyping up power looms.

        And accusing my comment of being luddism doesn't address my point at all- people close to the actual work the computer will be performing have an inherent advantage over people mired in the internal theory of how the computer works. They're not spending 60% of their time in efforts to justify their existence.
    • The extant literature on recent advances in software engineering encompasses the task of taking real world problems and finding real world solutions. In order to produce a huge system from a tremendous amount of primary and countless derived requirements, some measure of problem space reduction and abstraction must be performed. UML provides some of those tools. There is a job description for specialists that revolves around implementing the latest in software technologies to bring to market projects tha

  • isn't UML supposed to be a language? (Score:4, Interesting)

    by kruntiform ( 664538 ) on Tuesday May 13, 2003 @12:09AM (#5942512)
    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?
    • UML is kind of like 4GL smalltalk. --TRR

    • 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 n

  • Somebody forgot to review the transcript (Score:3, Informative)

    by Lumpish Scholar ( 17107 ) on Tuesday May 13, 2003 @03:13AM (#5943002) Homepage Journal
    ... there's the IEEE's effort on what's called the "sweet box of software body of knowledge."
    I'm sure this was meant to refer to the Software Engineering Body Of Knowledge (SWEBOK) [swebok.org]. It almost did.

  • Back to the future? (Score:4, Interesting)

    by Bazzargh ( 39195 ) on Tuesday May 13, 2003 @04:40AM (#5943240)
    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 [projtech.com] 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 [projtech.com]...ah well, at least the methodology wars are over - looks like the tool & book vendors won ;)

    - Baz
    • 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'...

    • CASE tools provide assistance in actually producing software

      Funny you should mention that. I have a tape of one of Grady's lectures where he said:
      "CASE tools allow poor designers to produce bad designs much more quickly."
      Not that it has anything to do with .NET or this article... :-)

  • Problem with "Executable UML" (Score:4, Insightful)

    by Tablizer ( 95088 ) on Tuesday May 13, 2003 @01:21PM (#5947185) Journal
    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.
    • Can you say, "Softwire"? I've never used it, but I think it has the same problems.

      My personal preference is to use my own notation (on small projects), sketch it out relationally, and then code the objects and data tiers separate.
  • 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 ?
    • Lack of publicity causing no-one to hear about it which means no-one talks about it... I've never heard of XPCOM but I've heard of the others. Grady is a man's name? You learn something new every day (especially when you know as little as me!)

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close