What This Book Is About

This book is about software development. It presents approaches and practices for the construction of software systems based on features, objects, components, and architectural patterns. This book presents the key phases of software development, as well as the artifacts produced during these phases. Above all, this book communicates our practical experiences in developing large software systems.

The approaches presented here were developed at Nokia. We authors were involved in the development of the presented practices, which are currently used within Nokia and in other organizations of different sizes.

The approaches are blended from several commercial object-oriented methods and our own process improvement, and they use the Unified Modeling Language (UML) to visualize their phase products and blueprints. We have tuned the processes for our own needs for the development of large interactive software products. In addition, we have scaled the practices down to be applicable for projects of a few persons.

This book concentrates on the key elements of software development—the elements that we have found most important. First, we present our industry proven process model, its phases and deliverables. To be useful in real-life software projects, the process framework must be understandable and clear. We discus how to utilize the process model in different kinds of software projects. Second, we present our practices for the development of the user interface and the data management. These elements exist in the majority of software systems, and are often the most difficult parts; still, the majority of publications and process models seem to ignore them. We discuss what kind of practices, software tools, and architectural solutions support the development of these parts.

We have noticed that object-oriented software development methods tend to be too big and complex for small software projects. Large and complicated systems require that processes and tools scale up. However, not all projects need such massive arsenals, and therefore, practices must also scale down.

Need for a Streamlined Approach

Instead of detailed and complex modeling notations, many companies simply need a practical process, clear notation, and “how-to” guidelines. We argue that it does not really matter if the selected practices do not cover all details of object paradigm. Instead, the approach should first concentrate on covering the most important aspects of software development. Only after that can the details be handled.

To help you meet these requirements, we present a simplified process tailored especially for small teams implementing their first or second objectoriented application [Jaaksi 98a]. It is a streamlined version of our standard process model presented in Chapter 1.

The simplified process uses UML. It also uses our standard two-path approach, enabling developers to view systems as collaborative entities. The process is tailored especially for small companies with little knowledge on object-oriented software development. The use of the process requires that the architecture of the developed system is fairly simple, and consists of only a few separate run-time components. It suits especially well for the applications consisting of only one executable program implemented in an object-oriented language.

Overview of the Approach

Our simplified process supports three aspects of the system to be developed. First, the process models the external functionality of the system; that is, what the system provides to the end user.

A debate has been raging on both CompuServe and the Internet lately about the use and abuse of accessing methods for getting and setting the values of instance variables. Since this is the closest thing I've seen to a religious war in a while, I thought I'd weigh in, not with the definitive answer, but with at least a summary of the issues and arguments on both sides. As with most, uh, “discussions” generating lots of heat, the position anyone takes has more to do with attitude and experience than with objective truth.

Let's see if I can get through this third column on how objects are born without blushing. So far we've seen two patterns: “Objects from States” and “Objects from Collections.” This time we'll look at two more sources of objects: “Objects from Variables” and “Objects from Methods.” All four patterns have one thing in common—they create objects that would be difficult or impossible to invent before you have a running program.

These patterns are part of the reason I am suspicious of any methodology that smacks of the sequence, “design, then program.” The objects that shape the way I think about my programs almost always come out of the program, not out of my preconceptions. Thinking “the design phase is over, now I just have to push on and finish the implementation” is a sure way to miss these valuable objects and end up with a poorly structured, inflexible application to boot.

“I'm not dead yet.” That's what I thought when Don Jackson at SIGS offered to put my articles together into a book. It's probably that every book I've ever seen with “Complete” or “Collected” in the title is no longer with us. Last I checked, I'm still here.

Having established that I am alive enough to be typing this, let's get to the point of the Preface—convincing you to buy this book. You are standing here trying to decide whether to spend your hard-earned dinero for that exquisite literature you saw with the swords and dragons and stuff on the cover or a collection of my articles. Here's my pitch—my entire career has been spent learning how to communicate with other people about programs. This book chronicles how I learned what I know and how I learned to tell people stories about it.

I just finished my first book, The Smalltalk Best Practice Patterns. It is easy to see how a book written end to end can have a single theme. This book has no such theme. It has a story—no, two stories.

The first story could be called “Kent Discovers the Importance of People.” I got into computing to avoid having to deal with people. As a sophomore in high school, I took physics instead of biology so I wouldn't have to try to understand “all that squishy stuff.” The rest of my academic career was spent in search of deeper understanding of the mechanics of things, whether the topic was computing or music.

Previously, I talked about how objects could be created from the states of objects that acted like finite-state machines (the “Objects from States” pattern). I'll continue on the theme of where objects come from for this and several issues.

I won't be saying much about the conventional source of objects, the user's world. There are lots of books that will tell you how to find those objects. Instead, I'll focus on finding new objects in running programs.

In the June issue, where I took on accessor methods, I stated that there was no such thing as a truly private message. I got a message from Nikolas Boyd reminding me that he had written an earlier article describing exactly how to implement really truly private methods. One response I made was that until all the vendors ship systems that provide method privacy, Smalltalk cannot be said to have it. Another is that I'm not sure I'd use it even if I had it. It seems like some of my best “reuse moments” occur when I find a supposedly private method in a server that does exactly what I want. I don't yet have the wisdom to separate public from private with any certainty.

On a different note, I've been thinking about the importance of bad style. In this column, I always try to focus on good style, but in my programming there are at least two phases of project development where maintaining the best possible style is the farthest thing from my mind. When I am trying to get some code up and running I often deliberately ignore good style, figuring that as soon as I have everything running I can simply apply my patterns to the code to get well-structured code that does the same thing.

Should you be using Distributed Smalltalk? That is the question I'll address here. This isn't a full-blown product review, nor a technical piece. I'll introduce the history and technical background of Distributed Smalltalk as they apply to the question of who should be using it.

First, what is Distributed Smalltalk? It is a Common Object Request Broker Architecture (CORBA)-compliant extension to ParcPlace System's Visual-Works developed and marketed by Hewlett-Packard. “HP? The hardware company? Those C++ guys?”

My first reaction when I saw that HP had done a Smalltalk product was, “What does HP know about Smalltalk?” The answer to this question is twofold. One answer is “a lot.” HP has been involved peripherally in Smalltalk since it first escaped Xerox. They were one of the first four companies to write a virtual machine. They have also had pockets of interest in Smalltalk ever since. Their 700 series of workstations has held the title for fastest Smalltalk for several years.

In the last issue, I wrote about what instance-specific behavior is, why you would choose to use it, and how you implement it in Smalltalk-80 …er…Objectworks\Smalltalk (which way does the slash go, anyhow?) …er… VisualWorks (is that a capital W or not?). This month's column offers the promised Digitalk Smalltalk/V OS/2 2.0 implementation (thanks to Mike Anderson for the behind-the-scenes info) and a brief discussion of what the implementations reveal about the two engineering organizations.

I say “brief discussion” because as I got to digging around I found many columns' worth of material there for the plucking. I'll cover only issues raised by the implementation of classes and method look-up. Future columns will contrast the styles as they apply to operating system access, user interface frameworks, and other topics.

I kind of ran out of steam towards the end of that last series on creating new objects. I think the message that many of the most important objects are not the ones you find by underlining nouns in problem statements is still valid. The objects that emerge (if you're watching for them) late in the game, during what is typically thought of as maintenance, can profoundly affect how you as a programmer view the system. By the time I got to the fourth part, though, I was tired of the topic. Those last couple of patterns still deserve some reexamination in the future.

What We'll Learn in This Chapter

A wrapper is a collection of one or more classes that encapsulates access to technology that isn't object-oriented to make it appear as if it is. A wrapper class is any class that is part of a wrapper. Wrapping, as shown in Figure 11.1, is used to provide OO applications access to hardware, operating system features, procedure libraries, function libraries, and even legacy applications. Wrapping allows you to retain your investment in older, non-OO technology by allowing you to reuse it in the new OO applications that you develop.

Now, where was I? Oh, yes. Last issue I talked about my philosophy of testing and presented a framework that supported writing unit and integration tests. But before that, I was talking about how to use patterns. I have spent a couple of issues designing the software to run a television and remote control, using patterns to guide every design decision.

This and the next column will discuss technical and philosophical matters. The technical material covers implementing and using instance-specific behavior, the idea that you can attach methods to individual instances rather than to a class. You might use it in animation or in building a Hypercard-like system. It is not a new idea. Lisp-based object systems have had it for years, and languages like Self rely on it exclusively. It is not well known in the Smalltalk community, though, and deserves a place in the mature Smalltalker's bag of tricks.

The philosophical material illuminates the differences between Digitalk's and ParcPlace's view of good Smalltalk style. ParcPlace grew out of a research atmosphere where truth and beauty were admired. Although established in business now, ParcPlace continues to favor elegant solutions. Digitalk has always been driven by the desire to build commercial software and has often been staffed with engineers whose experience comes from other languages. Digitalk's solutions tend to be more pragmatic and the workings easier to follow operationally, even if they don't have the most elegant high-level models.

My programming partner Ward Cunningham taught me to avoid complexity. In spite of my blue-chip, Silicon Valley brat credentials, I was never a very good programmer. Ward has more programming talent than I do, but he still programs simpler stuff, not because he must, but because he chooses. That is a big part of my success to date—picking development priorities and ignoring interesting side issues.

This was my first technical article. I was lucky to write it with Ward, because he had a pretty good handle on how to focus an article. That was the lesson of this paper for me—focus. I can remember discussing for days what the one single point was we wanted a reader to take away. That was a powerful lesson, and a bit painful, too. Ward and I had been working on lots of exciting stuff. I wanted to talk about all of it. Ward leaned and leaned on finding the one point that stood above all others. Finally we hit on this one.

The article introduces the Cunningham Diagram, a diagram with much the same information in it as Jacobson's Interaction Diagram, but (to my eyes, anyway) much more artistically rendered. As far as impact goes, this paper was a dud. The two good ideas here—the diagram itself and a tool for constructing it from running code—both disappeared without a trace.

A funny thing happened on the way to objects. There was this C++ juggernaut that was supposed to trample all in its path. I can remember hearing all the talk at OOPSLA '86 in Portland about how C++ was the language for objects. “Too much momentum.” “Too many C programmers.” “The alternatives are too flaky.” Everything else was going to be trampled. Period. In spite of this, a thriving market has grown around Smalltalk, the granddadly of pure object languages. It may be a fraction of the C++ market, but it is currently the scene of enormous technical and business energy. I make my living with Smalltalk, so my opinions on the matter are suspect, but I'll present the facts of the products in the market and let you draw your own conclusions.