DekGenius.com
Team LiB   Previous Section   Next Section

3.9 Object-Oriented Analysis and Design

The steps before programming anything, other than a trivial demonstration program, are analysis and design. Analysis is the process of understanding and detailing the problem you are trying to solve. Design is the actual planning of your solution.

With trivial problems (such as computing the Fibonacci series[1]), you may not need an extensive analysis period, but with complex business problems the analysis process can take weeks, or even months. One powerful analysis technique is to create what are called use-case scenarios, in which you describe in some detail how the system will be used. Among the other considerations in the analysis period are determining your success factors (how do you know if your program works) and writing a specification of your program's requirements.

[1] The Fibonacci series is the values 0,1,1,2,3,5,8,13.... The series is named for Fibonacci, who in 1202 investigated how fast rabbits could breed in ideal circumstances. The series works by adding the previous two numbers to get the next (thus 8 is the sum of 5+3).

Once you've analyzed the problem, you design the solution. Imagining the classes you will use and their inter-relationships is key to the design process. You might design a simple program on the fly, without this careful planning; but in any serious business application, you will want to take some time to think through the issues.

There are many powerful design techniques, you might use. One interesting controversy that has arisen recently is between traditional object-oriented design on the one hand[2] and eXtreme programming on the other.[3]

[2] See The Unified Modelling Language User Guide, The Unified Software Development Process, and The Unified Modelling Language (UML) Reference Manual, by Grady Booch, Ivar Jacobson, and James Rumbaugh (Addison Wesley).

[3] See Planning Extreme Programming by Kent Beck and Martin Fowler (Addison Wesley).

There are other competing approaches as well. How much time you'll put into these topics will depend, in large measure, on the complexity of the problems you are trying to solve and the size of your development team.

My personal approach to managing complexity is to keep team size very small. I have worked on large development teams, and over the years I've come to believe that the ideal size is three. Three highly skilled programmers can be incredibly productive and with three you don't need a manager. Three people can have only one conversation at a time. Three people can never be evenly split on a decision. One day I'll write a book on programming in teams of three, but this isn't it, and so we'll stay focused on C# programming, rather than on design debates.

About the Examples in This Book

Object-oriented programming is designed to help you manage complex programs. Unfortunately, it is very difficult to show complex problems and their solutions in a primer on C#. The complexity of these problems gets in the way of what you're trying to learn about. Because of necessity, the examples in this book will be extremely simple. The simplicity may hide some of the motivation for the technique, but the simplicity makes the technique clearer. You'll have to take it on faith, for now, that these techniques scale up well to very complex problems.

Most of the chapters of this book focus on the syntax of C#. You need the syntax of the language to be able to write a program at all, but it's important to keep in mind that the syntax of any language is less important than its semantics. The meaning of what you are writing and why you're writing it are the real focus of object-oriented programming and thus of this book.

Don't let concern with syntax get in the way of understanding the semantics. The compiler can help you get the syntax right (if only by complaining when you get it wrong), and the documentation can remind you of the syntax, but understanding the semantics, the meaning of the construct, is the hard part. Throughout this book, I work hard to explain not only how you do something, but why and when you do it.

    Team LiB   Previous Section   Next Section