Developing Object-Oriented Software

An Experience-Based Approach
IBM Object-Oriented Technology Center
Prentice Hall PTR
ISBN 0-13-737248-5
HB, 636 pp.

As a Technical Director at Electronic Arts, I often despaired of getting good quality TDDs (Technical Design Documents) from project teams (internal or external). Some of the reason was that developers just didn't want to think about what they were going to do — they just wanted to do it. But a lot of the reason was that we didn't have a good example to provide. All we could give out was an outline and feedback on drafts provided by the team (TDDs done for previous products were confidential and not commonly distributed). A complete example of a well-done TDD would have been very useful and we often discussed creating one, but our jobs just never gave us the time to do it (and nobody was going to pay us tens of thousands of dollars to spend a couple of months building it).

A group of top-level "object technology experts" from IBM's Object-Oriented Technology Center (OOTC) has undertaken the task for us in Developing Object-Oriented Software. IBM established the OOTC in 1992, and members of the OOTC have been involved in over 70 OO projects since its inception, helping IBM software engineers test methodologies and establish a standard "best of breed" process for creating products using OOAD and OOP. This volume is the specification for that best practice, emphasizing the output of the process (the "Work Products") and their organization (the "Project Workbook"). Designed to distribute knowledge about IBM's suggested format for Project Workbooks, Developing Object-Oriented Software is divided into four Parts: Key Messages; Development Process; Work Products; Work Product Construction Techniques; Case Study; and Appendixes. The bulk of the book (almost 300 pages) contains definitions of 48 different Work Products.

The Work Products are divided into eight categories: Requirements; Project Management; Analysis; User Interface Model; Design; Implementation; Testing; and Appendix. Each Work Product Definition is covered in a chapter which includes sections on Description, Purpose, Participants, Timing, Techniques, Strengths, Weaknesses, Notation, Traceability, Advice & Guidance, Verification, Examples, References, and Importance. Definitions run two to twelve pages, and are easily read during a short break, bathroom trip, or long compile cycle.

The strong emphasis on analysis products (requirements and analysis) is, in my experience, not common to game development teams. We tend to emphasize project management (sometimes), implementation (always), and testing (always) at the expense of analysis and design (remembering that we're talking about program design here, not product design). Most academic or "scholarly" books on software engineering have a strong bias toward analysis, and I think we have something to learn from that. Now that the OOAD tool community is standardizing on a notation and working toward interoperability of OOAD tools, we'll be seeing more and more material dedicated to Universal Modeling diagrams, Object Interaction Diagrams, and the like — and we'd better get used to it.

Developing Object-Oriented Software functions reasonably well as a survey of project tasks (as you might expect). Once of the major uses for DOD DIDs is to demonstrate just how much information there is to collect about a programming project, and just how many tasks there are to do. Our tendency is to focus entirely on implementation, which makes the job harder. If you were to compare the output documentation on a product or an engine with the list of Work Products in this book, you'd see how much data we're leaving behind when we "finish", leaving the "paperwork undone", as the saying goes.

The documents described in Developing Object-Oriented Software represent a quantum leap over the previous document lists I've seen and used professionally. Both EA's TDD outline and the DOD DIDs (Data Interface Documents???) tell you a lot about what to include, but not much about how to show or organize the information. This book tells you, then it shows you, then it shows you again. The examples are generally clear and concise, showing what needs to be shown with a minimum of fluff, and the definitions are as clear-cut and complete as reasonably practical.

On the negative side, this volume doesn't substantially address our primary focus — real-time, performance oriented software. Most OO books don't, although some make a nod toward the differences between real-time and non-real-time software by including two examples or case studies. I think that the fact of the matter is that real-time systems are far more difficult to analyze, design, implement, and especially debug; and the state of the art in OOAD, OOAD notations, and OOAD tools is just not yet advanced enough to do the job thoroughly and effectively. That caveat aside, this volume presents a good collection of practices, processes, and documents, many of which are useful even to those of us out on the cutting (or bleeding) edge. Technical directors, engineering leads, and programmers of reusable engines in particular will want a copy of Developing Object-Oriented Software for their shelf.

Powersoft Optima++
Borland C++ Builder

Remember working with DOS? Ah, for the Good Old Days, when you could knock out a quick utility with a command-line interface, use the batch facilities to handle multiple files, and you were on your way. Nobody, not even the Artists, expected more from development tools and utilities. Now, of course, utilities must be developed in Windows, with the design time and effort (not to mention programming) that implies (I hope I'm not the only one who has spent hours trying to get all the controls to line up just right ;-)). MFC and OWL have attempted to simplify programming for Windows, Visual Basic has attempted to simplify programming for Windows, and Delphi has attempted to simplify programming for Windows. But they all have some disadvantage which makes them unsuitable for me: MFC/OWL are just about as much to learn as the Windows API itself; Visual Basic is so close to C I always find myself putting semicolons where they don't belong; and Delphi is a nice tool but it's Pascal, and I find switching between C++ and Pascal really annoying.

So along comes Powersoft with Optima++, followed by Borland with C++ Builder. These are a pair of RAD (Rapid Application Development) tools which host C++ compilers. If you've ever used (or watched someone use) Visual Basic, and you hear the words "Visual C++", these tools are what you imagined (until you saw Visual C++ 1.0). I don't have the space here to give you an in-depth review of both of them, or to compare their features, but here's a quicky:

The two tools are roughly comparable. Each provides a Drag-and-Drop IDE for creating Forms (Windows), setting Properties (class attributes or data members), and attaching code to Events (class methods). Each provides a collection of components (controls, dialogs, system functions, etc.). Each provides a reasonably full-featured editor for writing code in and out of Event handlers. Each provides resource editing capabilities. The compilers are fast enough on small projects (I haven't built a large one yet, but I will). Each provides a class library which wraps basic Win32 functionality. Optima++ has a class browser, C++ Builder doesn't. Optima is built on Watcom compiler technology, C++ Builder on the Delphi IDE and Borland C++ compiler technology.

What the quick list doesn't convey is how much fun these tools are to play with. I've been programming for Windows on and off since about 1986 and I have never enjoyed it so much. I plan at some time in the future to do a more complete review and comparison of the various versions of Optima and C++ Builder, but right now I'd suggest you find a way to play with one or both of them (the low-end versions of the tools are priced at about $200 for Optima and about $100 for C++ Builder). You will undoubtedly find you like one more than the other. I like them both.

Copyright © Evan Robinson. All Rights Reserved.