Why we need each type of diagram.

How to draw each type of diagram.

How to read class diagrams drawn in other modeling notations.

How and when to use use-case diagrams, sequence diagrams, state diagrams, process models, data models, collaboration diagrams, and interface-flow diagrams.

This book is an extension of The Object Primer and in this chapter we'll extend our knowledge of object-oriented analysis-and-design techniques. This chapter is perfect for people who wish to gain a broad understanding of the analysis-and-design options that are open to them when developing a system.

Here is a great example of a column I wish I'd never written. It presents a new control structure to deal with the complexity of the Composite/Wrapper pattern used in the user interface code in Visual Works. I wrote the column, sent it off, then had a quick talk with David Liebs about the subject. “So you need to talk to a particular wrapper, eh? Why don't you keep a pointer to the wrapper you need to talk to and give it a useful name? Then you can just send it messages.” Duh…

The other aspect of the column I regret is that it seems to condone adding new control structures to Smalltalk. The meta facilities of Smalltalk are extremely powerful, but 99.99 percent of the time, you shouldn't use them. Oh, they'd get the job done alright, but at what cost?

When you write something like #wrapperSend:, you have to take off your application-programmer hat and put on your language-designer hat. The responsibilities of the language designer are ten times as great as those of an application developer. Whatever you do, you have to implement it and test it, sure, but you also have to document it like a new language feature, extend the programming environment to handle it smoothly, and worst of all, maintain it through all future releases of the image.

Okay, back to tilting at windmills. Sometimes I think people just don't get Smalltalk. Why in the world would you want a grungy old explicit case statement when you have a superior substitute in the polymorphic message? How could you read and write Smalltalk code for enough years to be able to implement new language features and not understand that you didn't need them?

I guess my tights and cape aren't far enough at the back of the closet…

As with the previous column, this column has a strong confessional flavor. I like using my mistakes for columns, because I'm sure there is something to learn there.

The meat of the column is good stuff—refactoring and adding stuff becomes easy. I can't imagine how many times and ways I have said this in the last ten years. This is one of my better attempts, because it doesn't just say it, it shows it. (See “Make it Run, Make it Right” for another example.)

When I started writing this, I felt like I was getting preachy. Maybe that's what's so good about demonstrating from my mistakes—I can't be preaching if I'm explaining how I screwed up.

The personal material up front shows that I was aware that my attention was wandering. I'm glad I kept it together enough to say something important here.

This is my abortive attempt to bring patterns to the masses. Dr. Dobbs (which I used to read as a Silicon Valley brat in the late '70s) called to ask for a pattern article. I thought, “Here is my chance to step outside the narrow confines of the object universe.”

Ha. Nobody got it. I'm sure I misjudged my audience, but I think there are more serious problems with the presentation here. Looking at the paper again, though, I'll be hanged if I can figure what. I'll take a shot at it, though.

One of the problems is certainly that I am talking about a different kind of pattern here than most people talk about. The patterns in the Design Patterns book, for example, show you how people use objects over and over. You can take the same approach to using a particular framework, however. People use MVC the same way over and over. You can write the things they do as patterns.

Part of the problem with the paper now that I look at it is that I got away from Ward's question, “What is the one thing you want the reader to take away?” This paper is all over the place. Another problem is that the paper isn't explicit about even those points that it does make. It tells a story (kinda), but it doesn't come out and say, “Communication is the problem.”

What features to look for in an object-oriented (OO) language.

We'll compare and contrast the leading OO development languages: C++, Smalltalk, Java, and ObjectCOBOL.

How to develop for the world of electronic commerce.

What other development tools you may need to successfully build OO applications.

In this chapter we will discuss what features to look for in an OO language, describing the main features of each of the leaders. We will also compare and contrast the languages as well as discuss how to build electronic commerce applications using OO development languages.

This was my last column, and the one I'm proudest of. I have a habit of trying to take lessons from the world around me. If I see a tree leaning against another tree I say, “What is that like? Well, if one person leans on another too long, they both end up falling down.” I always kept these little stories to myself, though.

For my last column, I decided to break out. By now I was fully confident in my ability to describe a technical situation. I'd never tried to describe something from the real world in a publication before. This was my first attempt.

Looking at it now, it looks clumsy, but I still really like the underlying story. I've probably told the parable of the woodpile twenty times in the year since I wrote it.

In a way, this column represents the shift that I had been undergoing all along. I got completely away from technical stuff and completely into people stuff, and I did it in people-y, proto-literate way.

The various trends and techniques in creating distributed applications.

How to distribute applications using client/server technology, taking both a two-tier and three-tier approach.

How to distribute the classes of your object-oriented application using traditional client/server approaches, object-oriented client/server (OOCS), and applets.

How to create applications using Common Object Request Broker Architecture (CORBA), a distributed object standard.

The architecture for application development is becoming more and more distributed. We're moving from the centralized mainframe approach popularized in the 1960s and 1970s through the client/server approach of the 1980s, into the distributed classes and distributed objects approaches of the 1990s. In this chapter we will compare and contrast these approaches, concentrating on object-oriented client/server design, a technique for distributing classes across a network of computers.

Why your persistence strategy is important for successful application development.

What terminology is commonly used with respect to persistence.

How to map objects to flat files.

How to map objects to relational databases, concentrating on several critical topics: the impedance mismatch; mapping objects to tables; implementing object relationships; inheritance mapping strategies; and mapping success factors.

How to use object-oriented databases and object/relational databases as your persistence mechanism.

Persistence deals with the issue of how one ensures that the objects that he or she works with last, or persist, between invocations of object-oriented applications. In other words, persistence addresses one's strategy for saving objects to permanent storage. There are four common mechanisms used to store objects: flat files, relational databases, object-oriented databases, and object/relational databases. Although you may have heard that mapping objects into a relational database is a nightmare, and it can be if you make a mistake, we'll see in this chapter that using relational databases to store your objects is a very viable approach to persistence.

This was the column that generated the most interest and email for me, all of it positive. Other than that, there's not much to say, except “Get to work writing tests—yeah, you, the Smalltalk hacker.”