What We'll Learn in This Chapter

It wouldn't be right to have a book about OO development without covering the most common OO development languages. It needs to be pointed out, however, that this book isn't about OO programming, it's about OO development. Although I could easily write a book about each language covered in this chapter I'm not going to. The fact is that all I want to do is to give you a brief overview of what each language is like and what is typically used for, that's it. If you want more then I highly suggest that you pick up one or more of the books that I've listed in the references section at the end of this chapter.

I have started and stopped working on this book several times. Each time I began writing the introduction to a paper, I looked at it about half way through and said, “This seems awfully arrogant and self-centered. It's all about me, not about Smalltalk. Who wants to read about me?” I gave myself a good old-fashioned Puritan lecture about the virtues of self-effacement, and quit writing.

Recently I got Natalie Goldberg's second book about writing, Wild Mind. Her first book, Writing Down the Bones, was a collection of exercises for freeing the flow of ideas from mind to paper. I was reading Wild Mind sitting on a smooth teak bench in the Rose Garden of the Royal Botanical Gardens in Sydney. The yellowy autumn morning sun was baking the smell out of the roses. I read a comment another author made about the first book: “Why Natalie, this book should be very successful. When you are done with it, you know the author better. That's all a reader really wants, to know the author better. Even if it's a novel, they want to know the author.”

Creaking teak as I sat back. A flutter of wings as the gathered ibis around me took off. I blinked my eyes, hard. If a novel is about getting to know the author, and a book of writing exercises is about getting to know the author, then why shouldn't a book of Smalltalk essays be about getting to know the author?

IT'S THE OBJECTS, STUPID

Sometimes it takes me a while to see the obvious. Sometimes even longer than that. Three or four times in the last month I've been confronted by problems I had a hard time solving. In each case, the answer became clear when I asked myself the simple question, “How can I make an object to solve this problem for me?” You think I'd have figured it out by now: got a problem? make an object for it.

What We'll Learn in This Chapter

Over the past 15 years we have seen a general migration from highly centralized mainframe computers with dumb terminals to more and more decentralized information technologies. In Figure 5.1 we see how information technology is slowly evolving from mainframe technology to client/server technology to distributed classes and finally to distributed objects. In this chapter we will discuss the merits of all four of these technologies, concentrating on the reality of today and the near future: distributed classes and distributed objects.

What We'll Learn in This Chapter

The vast majority of business objects must be persistent, or in other words they need to be saved to permanent storage so that you can work with them in the future. Fortunately or unfortunately depending on your point of view, we have several mechanisms that we can use to make our objects persistent: flat files, relational databases, object-oriented databases, and object/relational databases. We will cover each of these mechanisms in detail, discussing the issues for how to use them to make your objects persistent.

You can't argue with inspiration (or deadlines). I started to write the final column in the sequence about using patterns for design, but what came out was this. It describes some work I have been doing with a framework that takes the tedium out of writing tests. I'll get back to the pattern stuff in the next issue.

Smalltalk has suffered because it lacks a testing culture. This column describes a simple testing strategy and a framework to support it. The testing strategy and framework are not intended to be complete solutions, but, rather, are intended to be starting points from which industrial strength tools and procedures can be constructed.

The article is divided into four sections:

• Philosophy. Describes the philosophy of writing and running tests embodied by the framework. Read this section for general background.

• Framework. A literate program version of the testing framework. Read this for in-depth knowledge of how the framework operates.

• Example. An example of using the testing framework to test part of the methods in Set.

• Cookbook. A simple cookbook for writing your own tests.

THIS BOOK is about:

• The Unified Modeling Language (UML), and how to use it effectively

• Architecting your applications so that they're maintainable and extensible

• Analysis, so you know what you have to build

• Design techniques, so that you know how you're going to build your application

• Creating applications for stand-alone, client/server, and distributed environments

• Using both relational and object-oriented (OO) databases to make your objects persistent

• Collecting the right metrics to improve your development approach

• Applying OO patterns to improve the quality of your applications

• Testing approaches to ensure that your applications work

• User interface design, so your users can actually work with the systems that you build

• Coding applications in a way that makes them maintainable and extensible

Welcome to Building Object Applications. To make this book easier to work with it is divided into the following five parts:

Part I Introduction

1. Chapter 1 Where We've Been Before—Object-Oriented Concepts and Techniques

Part II Object-Oriented Analysis, Design, and Architecture

1. Chapter 2 Bubbles and Lines—Useful Diagrams for Object-Oriented Analysis and Design

2. Chapter 3 Improving Your Design—A Class-Type Architecture

3. Chapter 4 Reusing Your Development Efforts—Object-Oriented Patterns

4. Chapter 5 Development in the 90s and Beyond—Designing Distributed Object-Oriented Applications

What We'll Learn in This Chapter

I'm a strong believer in something called full life-cycle object-oriented testing (FLOOT), which involves testing your object-oriented applications throughout the entire system development life cycle (SDLC). We'll see that there are many reasons why you want to test throughout the entire SDLC, not the least of which is if you leave testing to the end of a project it typically doesn't get done properly. In this chapter we will discuss a number of testing techniques that together form a FLOOT process (there has to be a music joke in here somewhere).

AS A BROAD-FACED INTRODUCTION to object-oriented (OO) technology, this is one of the best books that I have read. It is well written, employing a style that makes it enjoyable to read and easy to understand. Although it covers a diverse range of topics, the coverage is balanced and the topic selection is well chosen.

Topics that usually receive only passing mention in other texts of this kind are included. The first part of the book looks at where we have been in the field and lays a foundation for the rest of the text by introducing general concepts. The second part focuses on architectural issues, and the subjects of object-oriented analysis, design, and patterns are introduced. The author chooses to feature UML notation in the short examples that are presented. The third part introduces OO matrics, user interface design, and OO databases and presents a brief survey of some OO languages. The fourth part of the book focuses on OO testing. All these subjects are covered in much greater detail in more specialized books—but that is to be expected in a book of this kind. Experienced practitioners may object to the omission of important topics and incomplete coverage of some subject areas, but this book is not meant to be a rigorous treatise on object technology; rather, it is a compelling early read for those interested in this area of software development.

Introduction

Having established the framework for the phased development of a system we now go on to look at the techniques that are available to you during those phases.

The purpose of this chapter is not to present all known techniques in an encyclopaedic way. Rather, it is to present sufficient information on a representative selection to allow you to make a first selection of a subset for your own project. As you read each précis, you can decide which of the techniques presented are not of interest and those that might be.

In the subsequent phase-orientated chapters each technique is presented with further detail in the context of the phase or phases where it is of use. Thus techniques applicable to, say, the System Definition Phase can be read and compared. Should you still feel that a particular technique is or may be of use, you can refer for complete information to the source material listed in the bibliography.

Similarly, all of the descriptions of the techniques in later chapters are necessarily simplifications. Remember that they are given not so that you can learn how to use the technique – for that you must turn to the authoritative references and suppliers. The purpose is solely to give you sufficient flavour of each technique for you to judge whether further evaluation could be worthwhile.

For each candidate technique you should aim to adopt, adapt or reject it.

The aims of System Acceptance

The system resulting from the Production Phase must now be tested against the Functional Specification to your client's satisfaction. There are two principal reasons for giving the System Acceptance process a phase of its own:

• firstly, to emphasise the importance of careful preparation for it and proper orientation of the preceding phases towards it;

• secondly, because possibly for the first time since System Definition and the production of the Functional Specification, your client will once more play a major role.

Formal acceptance of the system by your client – in other words, a signature – is as important as his formal acceptance of the Functional Specification. It records his agreement that you have carried out your commitment to build his system.

It is likely that, if you have a commercial contract with your client, payment of some portion of the contract price will be dependent on the system's successfully passing an agreed Acceptance Test.

Throughout the preceding phases we have emphasised the need to prepare for Acceptance well ahead of the date of handover. The earlier the Acceptance Test is defined, for instance, the earlier the system can be checked out against it by its implementers. Above all, however, acceptance will not always be simply a matter of running some tests on the system and walking away. You may well be involved in a major handover operation requiring the conversion of the user's organisation and operational procedures, cutover from an existing system, conversion of existing databases to new formats, periods of parallel running, training of staff and so on.

The cost of software development is now the dominating cost in computer systems. As hardware costs decline, improved efficiency of software production becomes the key target if further reductions in computing costs are to be achieved. Accordingly the Alvey Committee identified software engineering as one of the four underlying technologies for the UK national programme of cooperative research in information technology.

Coming as it does at the start of the Alvey programme, I welcome this book by Martyn Ould and Nick Birrell, for it presents a picture of software engineering techniques that are already in existence and can therefore be exploited now. If the techniques set out in the book are widely applied we can look forward to a very significant improvement in the efficiency of software production.