Effective Java, C# Essentials, Essential Java Style

This article appears in slightly different form in the July/August 2002 issue of IEEE Micro © 2002 IEEE.

Programming Books

This time I look at books designed to help you program in Java and Microsoft's new language for the .NET framework, C#. When I first wrote about Java (Micro Review June 1996), I said

I think Java will eventually replace C, but I think C++ will persist as its competitor for a long time. That conflict will probably follow the model of the RISC vs CISC wars, so that ten years from now it will be hard to know which is which.

There are still four years to go for that prediction, but whatever happens to C++, it's already hard to tell C# and Java apart. The books I look at this time often sound as if they are quoting each other, almost word for word, whether they deal with C# or Java.

Effective Java by Joshua Bloch (Addison Wesley, New York NY, 2001, 268pp, ISBN 0-201-31005-8, www.awl.com/cseng $39.99)

Joshua Bloch is the ideal person to write about using Java effectively. He has a distinguished academic background and works as a software architect at Sun, where he has been since 1996. He designed and implemented the collections framework and the java.math package.

Bloch borrows the title and format of his book from Scott Meyers' Effective C++. When I reviewed Meyers' book (Micro Review, Nov/Dec 1994), I wrote that Meyers should have titled it "C++ Traps, Pitfalls, and Swindles" (an allusion to a chess book by Fred Reinfeld). I wrote

You can look at this book two ways. From one point of view it is an enormously helpful compendium of practical advice on C++ programming. From another angle it is a point-by-point condemnation of C++ as an unusable, unintuitive programming language.

I'm happy to say that only the final two chapters -- on threads and serialization -- of Bloch's book make me feel that way. The behavior of threads appears to be quite unintuitive and to depend on a continually changing memory model. Serialization appears to have insoluble problems, because it conflicts with the modularity and encapsulation that are at the heart of the object oriented model. The remainder of the book, however, leaves me with a decidedly more positive impression of Java and the care with which Sun continually reviews and improves it.

I do not always read every word of books that I review, but I read every word (and every line of code) of this one. I read it sequentially from cover to cover, but you don't need to. Like Meyers' book this one consists of short essays (57 in this case), grouped into 9 topic areas. Bloch wrote the essays independently, so you can just read what interests you. I found all of it fascinating.

Bloch writes about Java programming style, but rather than doing so abstractly, he stands knee-deep in implementation details. He often bases his analysis of a situation on how the Java virtual machine is likely to behave. He also brings in his deep knowledge of and respect for the Java libraries. He points out that it's foolish to waste your time inventing ad hoc solutions to problems, when experts have already solved those problems and made the solutions conveniently available in libraries like java.lang and java.util. This seems too obvious to mention, but many programmers, unfortunately, need to hear this advice.   

Object oriented programming is a good example of the principle that there's no such thing as a free lunch. Bloch's essays entitled "Favor composition over inheritance" and "Design and document for inheritance or else prohibit it" illustrate this point clearly. You promote reuse if you provide a class with the intent that someone in another company working in a different package can extend it (that is, create a subclass) by overriding some of its methods. The costs of doing this -- often overlooked, even by experienced designers -- are reduced modularity and greater vulnerability to errors or malicious attacks. Allowing subclassing reduces modularity because you must document details of your implementation. For example, you must say (and commit never to change) when and why you invoke the overridable methods within your own class -- details that would otherwise remain private. Allowing subclassing increases vulnerability because you must also declare some methods and fields of your class to be protected, that is, available to the subclass. If you were not making the class available for subclassing, you would declare those methods final and the fields private.

The essays just discussed are in Bloch's chapter on classes and interfaces. Many companies sell Java-based software. They design interfaces and provide classes to implement them. How well they do this can mean the difference between a successful product and one that generates more support costs than revenue. If your company sells Java-based software, it's a very good idea to ensure that you are familiar with the issues Bloch discusses.

The other parts of this book are just as valuable. Bloch consistently returns to the themes of usability, robustness, and flexibility. He also addresses efficiency (for example, pointing out the costs of string concatenation), but warns that optimizations often cost more than they save. He also points out that the design of the public interfaces can sometimes have a much greater effect on performance than tinkering with implementations. First write a good, modular program. Then measure performance with profiling tools to find out where the bottlenecks are. Tinker with the few small places that might have a big effect. Then measure again, because optimizations don't always have the effect you think they will have.

Every bit of this book is essential for Java designers. Reading this book before you start delivering products can easily repay its cost thousands of times.

C# Essentials, 2ed by Ben Albahari, Peter Drayton & Brad Merrill (O'Reilly, Sebastopol CA, 2002, 202pp, ISBN 0-596-00315-3, www.oreilly.com, $24.95)

The C# language is Microsoft's answer to Java. Java programmers should have no trouble learning to program in it. Rather than running on a Java virtual machine, C# runs on the .NET runtime environment, which is called the common language runtime (CLR). All languages on the .NET platform compile into CLR modules and can interoperate with each other, including seamlessly using each other's objects and classes.

This book provides an excellent overview of the basic language and its features. Like Java, however, C# relies on an extensive library. For C# the library is the .NET framework class library (FCL). This book provides only the sketchiest overview of the FCL. As it has for Java, O'Reilly will probably produce a large stack of books on the C# library and environment. Until then, you'll have to work with the overview documentation that Microsoft provides with the .NET framework and its software development kit (SDK).

One interesting feature of the FCL is its support for regular expressions. This is a natural outgrowth of Microsoft's support for XML. If you're going to be working with a lot of plain text files, which is what XML files are at heart, you need powerful tools for manipulating them. Regular expressions provide such a tool. The book provides a nice summary of the FCL support for regular expressions, which parallels that of the Perl language.

The book is short. It does not pretend to be more than a concise summary of the language and its relationship to its environment. Nonetheless, it contains lots of useful information. The writing is clear and concise, and the material is well organized. If you're starting to program in C#, this is a good book to have handy.

Essential Java Style - Patterns for Implementation by Jeff Langr (Prentice-Hall, Upper Saddle River NJ, 2000, 300pp, ISBN 0-13-085086-1, www.phptr.com, $39.99)

This is a helpful book on the nuts and bolts of writing good Java code. At the same time it is an annoyingly curmudgeonly work. Langr continually rails against decisions that the designers of Java made a long time ago. Nobody can do anything to change those decisions now, so this carping is of little use to his readers.

Langr's subtitle plays on the idea of design patterns, a widely accepted way to describe and name designs for programming subsystems. Langr, however, does not write about architecture at that level. His patterns deal with designing and coding individual modules.

Langr blends valuable content with a clear, easily comprehensible, and visually effective presentation framework. He presents close to a hundred patterns, grouped into six groups, or categories. Each pattern answers a specific "How do I . . .?" question, making the book task oriented -- a rare but much appreciated characteristic of a programming book. Langr presents the patterns in a visual style reminiscent of good API documentation. Each pattern's entry begins with the pattern's name followed by a boxed table containing the question the pattern answers, a summary of how it does so, and references to related patterns. Langr follows the table with a few explanatory paragraphs and annotated code examples.

Langr gives his patterns names, rather than numbers, so that people can remember them more easily. This is a good idea, but names and numbers are not mutually exclusive. By numbering his patterns as well, he can make it easier for programmers to navigate to the information they are looking for. I hope he adopts this practice in future editions.

Langr comes from a Smalltalk background. Many of the underlying ideas come from Kent Beck's Smalltalk Best Practice Patterns (Prentice Hall, 1996). Few Java programmers are likely to have read that book, so this adaptation for Java will bring the patterns to a much larger audience.

In addition to the chapters that describe the patterns, Langr provides two other valuable discussions. The first is a long annotated example that illustrates many of the patterns. The second is a collection of hints for achieving good performance. Langr purposely avoids discussions of performance in most of his patterns. In this section he addresses a few Java-specific optimizations. Because implementations change, these hints may not apply to later versions of Java, but many probably will.

The book is a little dated, because it refers to Sun's JDK 1.1 and 1.2. Most of the information is still valuable, but a new edition would enable Langr to incorporate recent improvements and to remove obsolete warnings and workarounds. Even so, this book is well worth reading.

Enterprise Computing

This article appears in slightly different form in the May/June 2002 issue of IEEE Micro © 2002 IEEE.

In the March/April 1998 Micro Review, I reviewed a book by Roger Sessions about Microsoft's vision for distributed computing. Microsoft has continued to march down that road. As I found out at the VSLive conference in February 2002, they seem to have assembled all of the pieces (COM+, .NET, C#, Visual Basic) and are ready to put them together with XML into something called web services.

At the same time, Sun's strategy has been more visible. The Java Two Enterprise Edition (J2EE) has been in widespread use for two years. As I found out at the Java One conference in March 2002, Sun is extending the J2EE platform and using XML technologies to enable something called web services.

Books about these approaches abound. This time I look at a generic book about web services and several books about the Java approach to providing them.

Enterprise software is not an end in itself. I also look at a book that deals with content -- the reason for all that software.

Finally I look at a book about a topic that never seems to go away -- improving the software development process.

Web Services

Web Services Essentials -- Distributed Applications with XML-RPC, SOAP, UDDI and WSDL by Ethan Cerami (O'Reilly, Sebastopol CA, 2002, 288pp, ISBN 0-596-00224-6, www.oreilly.com, $29.95)

A web service, according to this book, is any service that is available over the Internet, uses a standard XML message system, and is not tied to a specific operating system. This general definition gives little insight into what they will look like and how they will affect our lives. I went to VSLive and JavaOne looking for a clearer picture, but they didn't give it to me. I am sorry to say that reading this book did not give me a clearer picture either.

The book does, however, give a good introduction to the technologies that everybody seems to agree will underlie whatever web services turn out to be. Those technologies are the acronyms mentioned in the book's subtitle: XML-RPC (the XML-based remote procedure calling protocol), SOAP (the simple object access protocol), UDDI (the universal description, discovery, and integration specification), and WSDL (the web services description language). These are the building blocks of a loosely coupled architecture for distributed applications.

Cerami is a programmer, and he writes for programmers. If you wish to understand the business case for web services, look for a different book. Cerami focuses on details of how to use the base technologies. Real XML files and real code fill the pages of his book. If you like to dig into such details, this book should make you happy.

Java Web Services -- Using Java in Service-Oriented Architectures by David A. Chappell and Tyler Jewell (O'Reilly, Sebastopol CA, 2002, 262pp, ISBN 0-596-00269-6, www.oreilly.com, $39.95)

At first glance this looks very much like the Cerami book, and you may wonder, as I did, why O'Reilly brought out such similarly titled books at essentially the same time. I don't have a good answer, because there is considerable overlap -- Cerami's book is full of Java code, for example. The Chappell and Jewell book, however, focuses more on the Java aspects of the subject. It also seems to cover the subject area more broadly. If you intend to work mainly on the J2EE platform, you can probably start with this book and skip the Cerami book.

Chappell and Jewell see interoperability as the point of web services. The service-oriented architectures they refer to in the book's subtitle are frameworks in which new and existing enterprise software packages can work together without knowing too much about each other's inner secrets. 

A service-oriented architecture is like a dating service for client/server relationships. Servers advertise their services (for example, I provide stock price quotes) in a registry. Clients look in the registry for a suitable server. They use the information they find there to establish contact, over the Internet or a company network, with the server and obtain the desired service (for example, tell me the current price of Microsoft stock).

Making this sort of thing work smoothly, without human intervention, between systems using disparate operating systems and languages requires an alphabet soup of standards. In addition to SOAP, UDDI, and WSDL, my notes from JavaOne mention:

• ebXML TRP, a business-to-business messaging standard based on SOAP
  
• JAX-RPC, a set of rules for generating Java code from WSDL
  
• JAXP, an API for parsing XML into SAX or DOM
  
• JAXR, an abstract layer to hide differences between registry APIs
  
• JAXM, a low level API, based on SOAP, for messaging

That doesn't include the ones that don't exist yet (JAXB and JSR-109, for example).

As anyone who has participated in standardization efforts knows, many factors influence the final outcome. And the final outcome is rarely final, because the pressures of ongoing development and de facto standards lead to a succession of versions, each introducing new features. Multiply this chaos by the number of standards involved in web services, and you can see what a confusing field it is.

Chappell and Jewell realized that a big part of their job in writing this book was to separate truth from hype and software from vaporware. They do a good job of making sense of the field as it is now (or was in March 2002 when this book appeared).

A wise developer, looking at this situation, would probably decide to wait a year or so for web services to settle down. But many companies, not wishing to miss the next big thing, are jumping into web services with both feet. If that's the situation you find yourself in, this book can save you a lot of grief. Don't approach web services without it.  

Java Enterprise Applications

As they did last year, Sun gave attendees a book at this year's JavaOne conference. Unlike last year's book, which contained interesting but disjointed case studies, this book focuses on application architecture. Arising out of the Java BluePrints program, this book lays out design patterns and best practices for building enterprise applications on the J2EE platform.

Designing Enterprise Applications with the J2EE Platform, 2d ed by Inderjeet Singh et al. (Addison-Wesley, Boston MA, 2002, 440pp, ISBN 0-321-12522-3, www.awl.com/cseng, $44.99)

The web services field is arcane and chaotic. J2EE application architecture is mature by comparison, and this book illustrates that point extremely well. You could use it as the textbook for a college course on the subject. Despite the large number of authors, the book is coherent and clear. It appears to speak in a single voice and tell a single story, without gaps or overlap. To my knowledge, nothing remotely like it exists for the .NET platform.

This book arises from the Java BluePrints program. In fact, its unofficial name is the BluePrints book. It culminates with a sample application (the Java Pet Store) that illustrates the principles and design patterns that the book discusses. The entire program, and this book in particular, are a model for the way all companies should support their products for developers. If you have anything to do with developing enterprise applications on the J2EE platform, drop everything and read this book from cover to cover.

  

Mastering Enterprise JavaBeans, 2d ed By Ed Roman, Scott W. Ambler, and Tyler Jewell (Wiley, New York NY, 2002, 672pp, ISBN 0-471-41711-4, www.wiley.com/compbooks, $45.00)

Ed Roman, CEO of the Middleware Company, is a developer who has been working with Enterprise JavaBeans (EJB) since they first appeared. He has taught the subject to many students. Scott Ambler is a columnist for Software Development and the author of many books on object oriented development methods. Tyler Jewell is a technology evangelist for BEA Systems and an expert on EJB. The first edition of this book, which appeared three years ago, was widely admired. Taking all that into account, I expected this to be an excellent book, and it lives up to that expectation.

To paraphrase Mark Twain, Enterprise JavaBeans are to JavaBeans as lightning is to a lightning bug. EJB is the Java equivalent of Microsoft's COM+ (see Micro Review, Nov/Dec 2001). It is a robust server-side technology designed to handle tricky functionality automatically in the runtime environment. Application programmers need not worry about transactions, persistence, or caching database information, for example. The EJB container can take care of these things for them.

This book teaches you EJB from the ground up. While far too many computer books are superficial -- filling an impressive 1000 pages with regurgitated manuals and specifications, this thick book is concise and focused. It deals with difficult issues and refers you to Sun's specifications for the minute details. It is both a textbook and a tutorial, but not the sort of tutorial that leads you through page after page of baby steps. It shows you code, discusses the key issues, and lets you try it out if you wish to do so. You can download all of the code from the book's website.

When Ed Roman first encountered EJB, he struggled for months to understand the specification. Having become an expert the hard way, he resolved to write the book he wished he had been able to read then. Why reinvent the wheel? If you need to work with EJB, read this book.

Content

Enterprise Content Services by Greg Laugero and Alden Globe (Addison-Wesley, Boston MA, 2002, 204pp, ISBN 0-201-73016-2, www.awl.com/cseng, $29.99)

Greg Laugero is an expert in managing intellectual capital. Alden Globe is an expert in knowledge management. Together they founded Industrial Wisdom, LLC, a company that focuses on providing enterprise information to the decision makers who need it.

This book tries to put the horse back in front of the cart. The authors point out that managers often mistakenly assume that acquiring the right technology will solve their problems. The truth, however, lies in the old saw: first devise the process, then automate it. In the case of content management, this means examine your business goals and strategy to identify your information needs, then devise ways to develop and deliver that information automatically.

The authors devote a considerable portion of the book to an elementary explanation to managers about why they need to manage their enterprise information within the context of their business strategy and how to measure the benefits of doing so. Many managers in high tech firms probably already understand this. They should find the rest of the book much more interesting.

The authors move from the why of content management to the how of it. They lay out a practical, easy to follow process for identifying the enterprise information that is relevant to your business needs and for managing that information to meet those needs. They build this process around the following basic elements: knowledge storyboard, content inventory, and enterprise content catalog. These elements are just what you think they are, but the authors provide lots of practical advice to keep them from becoming too elaborate. Their basic ground rules are:

• Know the business problem and know the content
  
• Acknowledge that people and processes drive technology
  
• Be aware that the catalog is the foundation
  
• Think big, work small, deliver quickly
  

The main point of these rules is to focus you on a process that meets your business needs, not on flashy technology. If this book achieves that goal with a significant number of readers, perhaps it will help content management vendors focus more on the quality of their offerings and less on the lengths of their feature lists.

 

Process Improvement

Making Process Improvement Work -- A Concise Action Guide for Software Managers and Practitioners by Neil S. Potter and Mary E. Sakry (Addison-Wesley, Boston MA, 2002, 196pp, ISBN 0-201-77577-8, www.awl.com/cseng, $29.99)

Potter and Sakry are cofounders of a company that consults in the area of software process improvement. Both have been working in this area for many years. Like the content management book by Laugero and Globe, this book tries to bring its subject down to earth. It focuses on identifying specific business problems and addressing them with simple, practical, targeted steps.

Many companies take achievement of a specific level in the Software Engineering Institute's Capability Maturity Model (CMM) as a goal in itself. This leads them to introduce processes and paperwork into their already busy workflows without a clear idea of what all of this red tape is supposed to accomplish. Project teams quickly abandon these additions or learn to go through the motions. The business problems remain as they were.

Potter and Sakry suggest a different approach: focus on your organization's goals and problems, and tie improvement activities directly to current project work. Solve the most important problem first. When that solution is succeeding, address the next problem. Look at how your solutions relate to the CMM, but don't make your solutions broader than they need to be to solve the business problem. You can apply Laugero and Globe's maxim here: Think big, work small, deliver quickly. A little momentum goes a long way.

The book is concise. It contains a step-by-step procedure for identifying, simplifying, and carrying out process improvements that solve real problems. If anybody in your management has ever mentioned the CMM, you should buy this book.

Learning Proven Lessons

This article appears in slightly different form in the January/February 2002 issue of IEEE Micro © 2002 IEEE.

The books I look at this month cover a wide variety of subjects, but they are all about learning. None of them deals with a brand new topic. Two of them are new editions of successful books about important topics: XML and Perl. Two are successors or companion volumes to other works by the same authors: Gerald Weinberg on consulting and Kendall Scott on the Unified Process. One applies old principles to designing websites -- a no longer new, but still largely undisciplined activity.

These books illustrate an important idea. Fads come and go, but there is no magic. Fads become disciplines through patient progress, trial and error, and applying proven principles to new situations.

New Editions

XML Handbook, 4th edition by Charles Goldfarb & Paul Prescod (Prentice-Hall PTR, Upper Saddle River NJ, 2002, 1164pp plus 2 CDs, ISBN 0-13-065198-2, www.phptr.com, $49.99)

Prentice-Hall produces a series of XML books under the title The Charles F. Goldfarb Definitive XML Series, and this book is the flagship of that series. Some books in the series are pro forma attempts to describe logically necessary pieces of the XML world. They leave me unsatisfied, wondering "where's the meat?". This book, however, contains an overwhelming amount of meat.

On his website, www.xmlbooks.com, the senior author, Charles Goldfarb, lists and comments on hundreds of XML books, including 15 that he personally recommends. This one is first on his list. Here is what he says about it:

Everyone involved with the Web needs to know about XML: content creators, Website developers, programmers, and — most of all if you want your projects funded — managers. What reviewers have praised most about The XML Handbook is its ability to reach all these people, while still maintaining the accuracy and completeness that its technical readers require. So much has happened in the XML world since the last edition was published that we've prepared a revised and enhanced fourth edition with over 1200 pages and two CD-ROMs.

This may seem like shameless self promotion, but it's accurate. Goldfarb is essentially the father of XML. His deep involvement and many contacts make it possible for him to understand, make sense of, and explain the many application areas that have embraced XML. 

Many industries and application areas have turned to XML to help them standardize their information structures and business interactions. This has led to an alphabet soup with an oversupply of Xs. This book helps to sort out and demystify the new standards and terminology.

The accompanying CDs are a strong point of this book, because there are so many XML-related tools. It's hard to know which ones address the problems you're trying to solve, and of those, which are efficient and reliable. By collecting a large number of excellent free tools and explaining what they do, the authors have performed a service that you would have to spend a large amount of time to duplicate.

With all of this, XML is still a daunting area. Reading a book of nearly 1200 pages and exploring the contents of two CDs requires a large commitment. There's no royal road, but when you make that sort of commitment, it's nice to know you're not heading down the wrong path.    

Learning Perl, 3rd edition by Randal Schwartz & Tom Phoenix (O'Reilly, Sebastopol CA, 2001, 334pp, ISBN 0-596-00132-0, www.oreilly.com, $34.95)

People in the Perl community call this the Llama Book, because the cover bears the picture of a llama. Over the last nine years, thousands of programmers have learned Perl from the Llama Book.

I did not like the second edition of this book (Micro Review, December 1997) because I found many technically significant errors in it. When beginners see an unexpected result, they often cannot tell whether they have misunderstood an essential fact or simply encountered a harmless typo. For this reason, a tutorial full of errors is very hard to use. In response to my queries about the errors, O'Reilly technical support sent me a long list of corrections, so I assume they have fixed them all in this edition.

If this edition of the book is substantially error free, it's certainly worth looking at. The authors have a great deal of experience teaching Perl face to face with students. Their presentation and exercises have evolved as a result of that experience. In fact, they have essentially rewritten the book to follow their courseware more closely. Some of the structural changes make the material easier to digest. For example, they provide a gentler introduction to regular expressions -- a subject that could easily fill a book by itself. In fact, if you become intrigued with regular expressions, there is a whole book about them, Mastering Regular Expressions by Jeffrey Friedl (Micro Review, December 1997).

Unlike Charles Goldfarb, these authors are not the fathers of the subject they are writing about --  that distinction goes to Larry Wall. They are, however, recognized experts, active in the Perl community. Like Goldfarb, they can show you a path through a daunting body of material. The Perl community, like the XML community, is actively extending its reach, and it takes experts like Schwartz and Phoenix to keep track of all of that work and explain its significance. I like the fact that the authors tell you up front that you're not going to learn the material in a few hours.

If you're ready to learn Perl on your own, or if you want to teach an introductory course in Perl, this is the book to measure all others against.

Companion Volumes

More Secrets of Consulting -- The Consultant's Toolkit by Gerald M. Weinberg (Dorset, New York NY, 2002, 214pp, ISBN 0-932633-52-8, www.dorsethouse.com, $39.45)

In my review of the SHAPE Roundtable on Project Management (Micro Review, July/August 2001), I pointed out that some of the shared images that make that discussion work come from Gerald Weinberg's Secrets of Consulting (Dorset, 1985). Now Weinberg presents more secrets and a whole new set of images. The yes/no medallion, for example, reminds you to mean it when you say yes or no. And every time someone mentions the yes/no medallion in a discussion, I will think of the chapter from hell, Weinberg's wonderful illustration of why yes should mean yes and no should mean no.

In earlier books, Weinberg established many famous laws. This time he uses the metaphor of a consultant's toolkit to store items like the yes/no medallion, but he hasn't given up on laws either. For example, when one colleague used Weinberg's law of raspberry jam (don't spread it too thin) to question why he was writing a sequel to Secrets of Consulting, Weinberg answered with more laws. The law of strawberry jam says that if it has lumps, you can never spread it too thin. The law of grape jam says that if you don't expect much, you're unlikely to be disappointed.

Weinberg bases his consultant's toolkit on the self-esteem toolkit devised by family therapist Virginia Satir, who wrote the foreword to the secrets of consulting. He does this because, in the words of Peter Block, 

The person is the product. Working on becoming a more authentic, whole person is the best business strategy.

The elements of the toolkit come dangerously close to new age superficiality. The wisdom box, the courage stick, the wishing wand, the heart, and others all have a new age sound. Weinberg used his courage stick when he chose this framework. And his wisdom box told him that it would work, because he wouldn't be gift wrapping garbage. He has so much to say and so many instructive stories to tell that any reasonable framework would have served the purpose.

The book is short and hard to summarize. If you're a Gerald Weinberg fan, you don't need me to tell you to buy this book. If you're not, I think you'll find this book a delightful introduction to the man and his work.

The Unified Process Explained by Kendall Scott (Addison Wesley, Boston MA, 2002, 206pp, ISBN 0-201-74204-7, www.aw.com/cseng, $34.99)

In UML Explained (Micro Review May/June, 2001) Kendall Scott explains the unified modeling language (UML), which is at the heart of the unified process. Now he has written a companion volume to describe that process.

The unified process is fairly simple in its essence, but large and complex in its implementation. By omitting material on UML and project management, Scott is able to focus on the core of the process.

The unified process structures software development around five workflows, four development phases, and a large number of deliverables that arise from the workflows and phases. Scott imitates this structure in his book. Using the online bookstore application he developed for UML Explained, he explains the process about as clearly and lucidly as possible.

The unified process is to a certain extent an iterative and incremental approach to development, which inevitably invites comparison with extreme programming (XP). Scott examines the question of whether XP is a special case of the unified process, and decides that it is not.

Like XML and Perl, the unified process has a large body of contributors who continually refine and elaborate it. This short book can give you a roadmap. But if you want to understand the unified process, you must take the next step and use it in a real project. If you are trying to decide whether to use the unified process, this book can help you to make that decision. 

Old Principles

The MIT Guide to Teaching Website Design by Edward Barrett, Deborah Levinson, and Suzana Lisanti (MIT, Cambridge MA, 2001, 114pp, ISBN 0-262-02500-0, mitpress.mit.edu, $22.95)

Edward Barrett teaches in the MIT program in writing and humanistic studies. Deborah Levinson is a graduate of that program who now works as a designer. Suzana Lisanti directs web publishing at MIT. These authors do not focus mainly on engineering; they focus on teaching and communicating. They are skeptical of claims of new paradigms, a digital wonderland, and the death of print. They apply time honored principles to teaching people how to communicate via hypertext-based systems.

Unlike most website design books, this one covers topics like optimal class size and classroom configuration. It emphasizes the need for collaboration, and it focuses on traditional topics like understanding the audience and tailoring the communication to that audience.

If you need to understand or teach website design, you may find this book a lot more helpful than a shelf full of books on HTML or web graphics.

Holiday Reading

This article appears in slightly different form in the November/December 2001 issue of IEEE Micro © 2001 IEEE.

Many of us have a little time off at this time of year. Here are two books that are worthwhile and not too hard to read. Take some time to read about embodied interaction, and COM+.

Embodied Interaction

Where the Action Is -- The Foundations of Embodied Interaction by Paul Dourish (MIT, Cambridge MA, 2001, 245pp, mitpress.mit.edu, ISBN 0-262-04196-0, $35.00)

There is a broad consensus that computer-based tools are hard to use. Many people believe that the problem lies in the way we design and build these tools. Recently I have reviewed quite a number of books that address that issue.

In The Humane Interface (Micro Review, May/June 2000), Jef Raskin takes a user-centered approach, loosely based on ideas that cognitive psychologist Bernard J. Baars discusses in his book A Cognitive Theory of Consciousness (Cambridge, 1988).

In The Inmates are Running the Asylum (Micro Review, Sept/Oct 2000), Alan Cooper makes the business case for taking interface design out of the hands of programmers. Cooper wants us to base our designs on intimate knowledge of the target users and their jobs.

In the Social Life of Information (Micro Review, Jan/Feb 2001), John Seely Brown and Paul Duguid ask us to stop looking at every human activity as a form of information processing. They show how ignorance of the social context of human activities often leads to failed attempts to automate those activities. In the same issue of Micro Review I look at Contextual Design by Hugh Beyer and Karen Holtzblatt. That book describes elaborate procedures for understanding and using the social context that Brown and Duguid talk about.

Paul Dourish approaches the same issues as these other authors, but from a somewhat different point of view. He uses the term embodied interaction to tie together several threads: tangible computing, social computing, and the philosophical tradition of phenomenology.

Tangible computing makes computer mediated interactions more natural by imbuing common objects with digital capabilities. For example, a telephone answering machine uses a row of marbles to represent your waiting messages. You place a marble into a receptacle to hear the message, then put it either into the save bin or the recycle bin. The power of tangible computing is that it takes icons to a higher level by giving symbolic meaning to actual physical entities. 

Social computing tries to understand the social context of the tasks you plan to automate. The trick here is to see the orderly social conduct emerge from the seemingly chaotic details, yet not overlook the hidden lubrication that makes the machine run. Using techniques like those that Beyer and Holtzblatt discuss, you identify the lubrication and thus avoid the disasters that Brown and Duguid talk about. One idea that arises out of social computing is coupling. Coupling is establishing and maintaining the relationship between action and meaning. For example, when you move the mouse, you might be positioning the cursor to insert text into a document, but you might also be bringing it back to the center of the mouse pad, or you might even be clearing space to set papers next to your keyboard.

Phenomenology isn't new, but it's a lot newer than the Cartesian philosophy that underlies many current approaches to interface design. Unlike Descartes, the phenomenologists do not separate mind and body. Meaning, for the phenomenologists, arises from our interactions with the world. The idea of an affordance, prominent in Donald Norman's writings on usability, comes from the phenomenologist J. J. Gibson. An affordance (a doorway, for example) makes its use obvious through its form.  

These three threads underlie embodied interaction. We exist in the physical world. We exist in a social context. We derive and create meaning by our interactions with these environments.

This all seems pretty theoretical, and you may be inclined to contrast it unfavorably with the precision and clarity of modern software design and construction. Dourish anticipates this reaction and turns it on its head. He sees current software design methods as abstract and theoretical, because they model users and interactions without first observing them. These methods, in his view, rely on disembodied cognition. The methods he advocates require you to become directly involved with the specifics of the actual practices for which you intend to provide computer based support. 

Because his methods depend so much on the different details of different situations, he feels he cannot reduce them to rules or guidelines. Instead, he lays out the following design principles:

• Computation is a medium.
  
• Meaning arises on multiple levels.
  
• Users, not designers, create and communicate meaning.
  
• Users, not designers, manage coupling.
  
• Embodied technologies participate in the worlds they represent.
  
• Embodied interaction turns action into meaning.
  

Because these design principles require a design context to make examples comprehensible, Dourish applies them to an issue that most readers are likely to be familiar with: the debate between convergence and information appliances.

Convergence is the idea that a single computer will handle spreadsheets, word processing, email, phone, fax, TV, movies, news, and any other communication or content delivery applications you might think of. An information appliance is a specialized computer-based device (a microwave oven, for example) that is simple to use because it doesn't have to do everything. Are these both the future of computing, or do they conflict?

When Dourish views this debate from the viewpoint of embodied interaction, he sees each of these alternatives as a technological solution, a way that designers try to manage or overcome the barriers and boundaries between applications. Users, on the other hand might be more interested in separating their personal from their work information, but not in separating writing a document from sending it. Dourish's design principles call for making users, not designers, the arbiters of where to place the boundaries.

This book is important reading for anyone engaged in designing computer-based systems to support human activities. It is full of interesting ideas and insights. I recommend it.

COM+

COM and .Net Component Services by Juval Löwy (O'Reilly, Sebastopol CA, 2001, 362pp, www.oreilly.com, ISBN 0-596-00103-7, $39.95)

COM is the acronym for Microsoft's component object model. This book, despite its title, is not about COM or Microsoft's new platform, .NET. It's about COM+. This requires a little explanation, and who better to provide that explanation than Roger Sessions.

More than three years ago, I reviewed Roger Sessions' interesting book COM and DCOM -- Microsoft's Vision for Distributed Objects (Micro Review, Mar/Apr 1998). As Sessions explains there, Microsoft has a coherent strategy for distributed applications. This strategy leads to architectures somewhere between Windows-specific clients on a Windows-specific network and generic browsers on a generic intranet.

When Sessions was first studying COM, he was intrigued to discover an early version of Microsoft transaction server (MTS). MTS, as Sessions points out, has little to do with transactions. Instead, it definitively solves the problem of how to share resources among clients in a client/server environment in a way that scales easily to large numbers of low-volume clients. According to Sessions, every current solution to this problem follows the principles of MTS. The Sun Enterprise JavaBeans framework, for example, is almost identical to MTS.

This brings us to COM+, and the point of this lengthy explanation. COM+ is MTS. That is, when Microsoft brought out its new version of MTS, they renamed it COM+. It provides the component services for COM and for Microsoft's new platform, .NET. This, finally, explains the book's title. The rest of the book is easy to explain.

Löwy follows two threads more or less in parallel through the book. The first thread is a thorough discussion of each component service -- what problem it solves, how it solves it, and what to be aware of when you use it. The second thread is a step-by-step explanation of how to use each service, with realistic code examples. Both threads are useful, but I especially like the thorough discussions, because Löwy understands the material and explains it clearly.

The chapter on queued components is a good example of this pattern. Many designers know the benefits in system robustness and improved performance of calling some object methods asynchronously, that is, of having the method return control to the caller before completing the requested operation. Löwy reviews the benefits, discusses the ad hoc pre-COM+ solutions and the problems they cause, then describes the COM+ solution, which uses MSMQ (the Microsoft message queue) and queued components. He sketches the implementation architecture, so you have a good idea of how the system handles the asynchronous calls and what the performance consequences of using them are. From there he goes on to explain how to design, code, and manage queued components. He even includes a substantial section on pitfalls.

Löwy's appendixes provide additional useful material. One appendix provides motivation and documentation for a component you can download from the book's website. The component logs calls, providing a useful debugging tool.

Another appendix describes COM+ 1.5, a version that appeared as Löwy was finishing the book. Keeping this material separate is a good solution to this potentially troublesome problem. Probably the material will migrate into the body of the next edition of the book.

The book also treats the way that COM+ provides component services for .NET. The book does not cover .NET (or COM, for that matter). An appendix provides a primer on .NET for the uninitiated, though it's hard to see why the uninitiated would be reading about component services for .NET.

This is a good book about an important technology that promises to be central to systems development in Microsoft environments for a long time to come. If you don't already know this material, this is a good way to find out about it.

Managing Development

This article appears in slightly different form in the September/October 2001 issue of IEEE Micro © 2001 IEEE.

As I write, less than a week has passed since the terrible events of September 11, 2001. Like many Americans I am torn between two urges: on the one hand, to move forward with business as usual; on the other, to devote attention to understanding what happened, and why, and to form my own opinion about what our country should do about it. 

The compromise between these urges is this abbreviated column. Normally I seek to make my column valuable to you by calling your attention to worthy books or software. This column does that. Normally I add further value by analyzing and describing the products I review in the light of my experience in the computer field. This time I haven't achieved my usual level of analysis and description. In other words, this time I tell you about some books that I think you ought to read, but I may not give you sufficient information to let you come to that conclusion for yourself.

Requirements   

Exploring Requirements -- Quality Before Design by Donald C. Gause and Gerald M. Weinberg (Dorset House, New York, NY, 1989, 320pp, www.dorsethouse.com, ISBN 0-932633-13-7, $50.45)

The biggest problem with software development is knowing exactly what to build. Communication between developers and their customers faces many obstacles: 

• Different assumptions and terminology
  
• Intermediaries with their own assumptions and understanding
  
• Failure to understand and respect each other's expertise
  
• Insufficient time to build a common understanding of the desired final product
  
• All the ambiguities of natural languages
  

A charming example of the last point is the authors' Mary Had a Little Lamb heuristic, which encourages you to substitute synonyms for the words in a requirement. For example, Mary cheated an unsophisticated investor; Mary gave birth to a small good-natured child; Mary dined sparingly on mutton stew.  

A misunderstanding can cost a great deal to correct after the product is finished but very little to correct before the design phase begins. This more than justifies the cost of defining requirements carefully.

Twelve years after it first appeared, this book is completely relevant to today's development projects. Gause and Weinberg call on their many years of consulting experience to provide practical techniques for exploring requirements. That is, they show you ways to discover and overcome ambiguity, distinguish between requirements and preferences, and push back against constraints. They show you how to tell when you're done and how to translate requirements into acceptance tests. They even give you ways to make meetings more productive.

Given the frequent disconnect between "what the customer wanted" and "what the engineers built" -- the subject of a well known cartoon -- most companies would benefit greatly from improvements to the way they define requirements. This book is just what the doctor ordered. I recommend it to anyone who has anything to do with software development.

Mastering the Requirements Process by Suzanne Robertson and James Robertson (Addison-Wesley/ACM Press, Harlow England, 1999, 416pp, www.aw.com/cseng ISBN 0-201-36046-2, $47.99)

This book picks up where the Gause/Weinberg book leaves off. Gause and Weinberg describe a collection of valuable techniques. The Robertsons, based on their long and widely recognized experience, lay out a complete end-to-end process for defining sets of requirements that are complete, correct, and measurable.

The Robertsons call their process Volere. They don't say how they came up with that name, but I assume it has something to do with the Italian verb meaning "wish." The Volere process turns customers' wishes into a usable specification document. The process is far from linear. An overview diagram contains many circular paths and feedback loops -- as simple as possible, to paraphrase Einstein, but no simpler. Or as Gerald Weinberg says in his foreword, "every part of the process makes sense, even to people who are not experienced with requirements work." 

Several notable features make the Volere process especially worthwhile. The first is the freely available Volere template (www.guild.demon.co.uk/SpecTemplate8.pdf). You can adapt this template for a requirements process to your own situation. Of course, to fully understand it, you probably need to read this book.

Two other notable features work together to keep your specification documents on target. The first is the concept of fit criteria, and the second is the quality gateway. Fit criteria are the rules (generally involving numerical measurements) for testing whether the final system meets the given requirement. The quality gateway is a process for deciding whether or not to include a fully specified requirement in the final requirements set.

If you write requirements documents or specifications, reading this book is your first requirement.

Software Requirements by Karl E. Wiegers (Microsoft, Redmond WA, 1999, 366pp, www.microsoft.com/mspress, ISBN 0-7356-0631-5, $34.99)

This book covers much of the same area as the other two books in this section, but it does so from a software developer's point of view. It also expands the idea of requirements to include specifications, and it addresses the way the requirements process fits into the entire development management process.

Wiegers uses a fictional chemical tracking application to provide context for the discussion, but he sometimes abandons it and brings in situations from his own extensive experience. Either way, he tries to keep his techniques practical.

I especially like the When Bad Requirements Happen to Nice People section. There Wiegers outlines the problems that his book is meant to solve. For example, he warns against gold-plating, a situation in which programmers add features that they think users will like, inevitably at the cost of taking time away from the most important features. 

Naturally, the problems Wiegers sees overlap substantially with the ones that Gause and Weinberg and the Robertsons address. For example, the Robertsons' quality gateway avoids gold plating.

I'd read the Gause and Weinberg book before reading this book. If your main interest is software development, you might read this book instead of the Robertsons' book, but if you have time, read all three.   

Project Management

A Guide to the Project Management Body of Knowledge, 2000 ed by Project Management Institute (PMI, Newtown Square, PA, 2000, 228pp, www.pmi.org, ISBN 1-880410-23-0, $35.95)

Project management professionals apply a variety of theories and practices to their work -- some experimental, others tried and true. The combined lore of these professionals constitutes a large body of knowledge.

The PMBOK Guide, as this book is known in project management circles, identifies and describes the subset of that body of knowledge that the Project Management Institute deems generally accepted. It does not teach this body of knowledge, but it provides an excellent map, a well organized skeleton with a little flesh on the bones.

This is a basic reference for anyone seeking certification in project management. It is also a helpful guide for anyone seeking to understand the underlying model of that ubiquitous but inscrutable tool, Microsoft Project. If you use Microsoft Project, but don't always understand what it's doing, read this book.

While this book is basic, if your interest is in a specific aspect or field of project management, you should also look at more narrowly focused books. 

Information Technology Project Management by Kathy Schwalbe (Thomson/Course Technology, Cambridge, MA, 2000, 512pp, www.course.com, ISBN 0-7600-1180-X, $53.95)

The PMBOK Guide is a scant 228 pages. This book, at more than twice that length, seeks to flesh out the PMBOK and specialize it to a specific industry. Schwalbe writes in the format of a textbook, with discussion questions, exercises, and suggested readings. The layout and printing are not up to the standards of mainstream publishers, but if you can get past that, the book provides a great deal of information in an easy to assimilate format.

One attractive feature of this book is that it uses Microsoft Project to develop class projects. Using Microsoft Project without understanding the underlying project management model can be confusing and difficult. The examples in this book help you avoid the confusion.

Special Edition Using Microsoft Project 2000 by Tim Pyron (Que, Indianapolis IN, 2000, 1314pp plus CD, www.quepublishing.com, ISBN 0-7897-2253-4, $39.99)

This book is well organized, beautifully laid out and printed, well written, comprehensive, and insightful. The notes and cautions add real value by tapping into the author's extensive experience with the product. 

The detailed table of contents reflects the logical structure, and the excellent index makes it easy to find information in this huge volume.

If anything can make Microsoft Project comprehensible, this book is it. I recommend it to anyone who wants to use the real power of this tool.