Dr. Carlo Pescio Interview with Grady Booch

This is the original text of an interview with Grady Booch, later translated in Italian and published in Computer Programming. In the following text, CP stands for Carlo Pescio and GB for Grady Booch.

CP:
This is probably the Most Frequently Asked Question, but would you mind telling something about the UML. For instance, why did you decide to move the emphasis from a notation + methodology to a true modeling language?

GB:
Actually, this is a FAQ; i've written up a series of such FAQs, which appear on http://www.rational.com in the oo technology pages. Briefly, there are a two reasons for this change. First, it was clear that a number of users wanted the ability to adapt their own process to the UML; indeed, different domains demand different approaches. Second, the focus of the OMG RFP for OOAD is focused on modeling languages, not processes.

CP:
I've heard more than a few peoples saying that "UML is too hard/comprehensive". I guess this is because your preliminary documentation is quite different from the OOA/D books peoples are used to. But as you move from a methodology to a language, an higher degree of formalism is unavoidable. Don't you think that having to learn a more formal semantics will scare some of the analysts? I'm thinking e.g. to business experts who used to do the analysis, but had little computer science knowledge.

GB:
It is true that the UML is comprehensive; we have tried to address the traditional and contemporary modeling problems (class models, state machine models, etc). We have also tried to cover issues of business modeling (since they often flow into an oo system) as well as executable semantics. Further, we've tried to be forward looking, meaning that we are focused on software development trends, most notably issues of componentware, distributed computing, and net based applications. These elements are all covered by the UML. It is also true that the current UML documents are not highly approachable to the novice. Indeed, the introduction of these documents explicitly states so. However, these documents are meant to specify the language, not to explain it. This is not unlike, for example, the C++ ARM. This is not how a beginner would learn to programm in C++.

The amigos are writing three books to mitigate this problem: a user guide, a reference manual, and a book on process. In addition, we know of several other books in the works that will be using the UML. In fact, "Core Java" already contains some UML diagrams (based on the .8 work)

CP:
Do you consider existing CASE tools really appropriate for everyday work? I know many companies where CASE tools are mostly used as drawing pads, because nobody trust them enough in the reverse engineering step. So they have the ubiquitous problem of maintaining design diagrams as the code evolve. In some cases they just stop use the CASE tool after a while. Do you think your existing round-trip technology is good enough to be used in real-world projects, based on class libraries like MFC (with the macro syndrome) or STL (templates everywhere)?

GB:
This is more of a tool issue than a UML issue, so I'll be happy to talk with you more about this privately. The short answer is, yes, Rational Rose is appropriate for every day work and yes, people are using it for a variety of real world projects, a number of which they are betting their business on. This is not to say that any CASE vendor is happy with their current tool set: we are always improving the usability and functionality of our tools.

CP:
So lets talk a bit more about that. Isn't the jump from a programming language like C++ to a language like UML too big to be taken by a tool? For instance, a pointer in C++ may represent many things, among which:
- a USE relationship, with any cardinality
- an HAS-A relationship, with any cardinality, implemented with a pointer for whatever reason
How can you automatically reconstruct a meaningful diagram in UML which preserves the semantics of the C++ code?

GB:
Rose already does this today for C++ and other languages.

CP:
I'm not sure my question was precise enough. Naturally rose does a reverse engineering of C++ code, but my question was about the quality of the output model. Using the same example as in my original question (pointers), consider this code:

class A
  {
  int x ;
  } ;
class B
  {
  A* a ;
  } ;

GB:
We don't do it perfectly. If you have forward generated into C++ and then reverse generate back to UML, we keep comments around that give hints as to what the original model means. If you start with virgin code, then we make a best guess (usually specifying it as an association)

CP:
Also, using macro-intensive library like MFC is very similar to programming into another language. To derive a class from one of the MFC base classes as CView you cannot simply derive a C++ class from it, you also have to define your own message map and so on, as the Class Wizard does. But without a knowledge of the MFC unique needs, how can a CASE tool do the same? Naturally, MFC is just an example, perhaps one of the most widely used, macro-intensive libraries.

GB:
Now you are talking about moving forward from an existing framework... that's something we've been applying some ideas of wizards to help with.

CP:
You are probably familiar with the fact that in Europe, most of the development teams are small (e.g. 3-5 peoples) and have little or no hierarchy. Each of them do some analysis, design, coding, debugging, documentation. Or at least, they should. The pressure to skip everything but coding is great. Even more so if the next door guy is using Visual Basic to put together things at light speed. I've witnessed peoples doing quick and dirty coding and call it "rapid prototyping" or "incremental development" to show a respectable face. It seems mostly a matter of management awareness: in some cases, a quick hack is just "good enough", but not all the times. But is also a slippery path: how do we build awareness in upper management?

GB:
This is not a characteristic of just European projects. It is the case that in our work we see projects ranging from small teams to quite large organizations, and everything in between. Moreover; this is a topic for a book (gee, time for a plug: go read "Object Solutions") ;-)
As for things like Visual Basic: there are practical limits to the complexity of systems one can build with such tools. Indeed, this is why we have a Rose/VB connection: to leverage off the rapid development offered by VB yet offer architectural control via Rose.

CP:
Actually I did read your book. It is full of good advices for managers committed to using object technology. However, here the issue is a bit different. There is a folklore that VB-like tools have "practical limits" when addressing complex problems, but little hard data to show at the crucial moment. I'm not a VB-fan, but I can see that in many cases VB wins simply because is the best deal-of-the-moment, so if your concern is to have the application ready for yesterday, you may be tempted to discard long-term benefits for a short-term increase in productivity. In some cases, that's just fine because the application does not have to survive, the domain is a moving target, and so on. But how can developers help a manager, who is _not_ already committed to use object technology, to avoid the pitfall of using VB-like tools for larger projects, just because it worked just fine on small ones? And how do you draw the line to say "this is too complex for VB"?

GB:
It is even worse... there are limits to things like vb, but you rarely know that you will hit those limits until it is too late. The basic things i tell vbers is to have a clear sepation of concerns from the gui and the data... and to have at least a three tier architecure so that business rules can be isolated.

CP:
I'll resist the temptation to ask you something about the translational methods a-la Shlaer-Mellor :-). Instead, I'd like to ask you something about BON, which seems to have taken a very different approach to modeling than UML, mostly in favor of reversibility. For instance, in IEEE Computer 29/9 Kim Walden has been quite critic about elaborational methods were high-level concepts do not exactly mirror low(language)-level ones. What's your position on that?

GB:
I debated this position with Stephen at the most recent OOPSLA. I'm not familiar with Kim's work specifically.

CP:
Ok, I'll pose you another challenge :-)

Peter Coad, in his book "Object Models", briefly criticize other notations by saying "Class, state and function diagrams? Can you say entity-relationship, state-transition, and data-flow?[...]To suggest such a multimodel triad is to miss out entirely on paradigm change". Now, I'm sure you have something to say about that, and I'd be glad to know your opinion.

GB:
No answer on that.

CP:
What's the secret of your success :-)?

More seriously, only a handful of consultants have had your impact on the process, practice and language of software development. Did it happen by chance, serendipity, restless effort, or what else?

GB:
Probably a combination of the above. God has graced me with an ability to synthesize ideas and communicate them, and I take that gift seriously. I've definitely been in the right place at the right time more than once, as well.

Reader's Map

Several visitors who have read this article have also read:

Biography
Carlo Pescio holds a doctoral degree in Computer Science and is a consultant and mentor for various European companies and corporations, including the Directorate of the European Commission. He specializes in object oriented technologies and is a member of IEEE Computer Society, the ACM, and the New York Academy of Sciences. He lives in Savona, Italy and can be contacted at pescio@eptacom.net.