Object-Oriented Analysis and Design

Before you program anything, other than a trivial demonstration program, you need to take two steps: 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), 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.

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. How much time you put into design[4] before you begin coding will depend on the philosophy of the organization you work for, the size of your team, and your background, experience, and training.[5]

Tip

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 agree with one of the best developers I’ve ever met, Ed Belove, that the ideal size for a team of developers 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, so we’ll stay focused on C# programming, rather than on design debates.



[4] See The Unified Modelling Language User Guide, Second Edition, by Grady Booch, Ivar Jacobson, and James Rumbaugh (Addison Wesley, 2005).

[5] See Agile Software Development Principles, Patterns, and Practices by Robert C. Martin (Prentice Hall, 2003).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset