Object Oriented Analysis and Design
Imagine an aircraft factory where a new jetliner is being built. Picture several competent engineers and workmen working with specialized tools, constructing a marvel of technology. Can you visualize them working on pure intuition – grabbing the tools and settling down to work immediately? Or, do you see them working according to an elaborate design on which they have spent hours poring over each detail – working and reworking the design, and finally constructing the aircraft based on this design?
For the sake of the millions of people, who fly every day, let us hope that the latter case is true. After all, it is comforting to know that a lot of thought has gone into first making a model on paper, and then translating that into the physical jetliner. The same thing holds true for almost any item that is constructed. Fashion designers, for instance, put pen to paper before attacking the fabric with scissors. Architects spend hours drawing up blueprints before laying the bricks.
So, why should the construction of software be any different? According to a report published in Japan, “The software industry still relies mainly on the informal paper-and-pencil approach in the upstream development phases.”
It is this ‘paper-and-pencil’ approach that is termed analysis and design. When we analyze and design a system, we build a model of the system. The purpose of this model is to help us understand the reality that we are trying to create. This model is simpler than the system that is finally constructed. Not all the practical aspects of building a system for the real world can be reflected in the design. However, this does not undermine the importance of design.
We need to distinguish between the stages of analysis and design. The analysis phase considers the system as a solution to a problem in its environment or domain. Broadly speaking, analysis is the stage where the users and the developers of the system get together and arrive at a common understanding of the system. After all, software professionals cannot be expected to know the intricacies involved in the operation of air traffic scheduling.
Similarly, airport personnel are not expected to know the syntax of programming languages. In order to build software for air traffic scheduling, both, the software professionals and the airport personnel must speak the same language in terms of the vocabulary of the problem domain.
Work in the design stage is comparable with that of an architect or a fashion designer. The designer generates the blueprint of the system that is to be implemented. In this stage, the developers of the system document their understanding of the system.
Just as in the procedural approach, several gurus propounded their theories of the methodology for analysis and design, several methodologies for object oriented analysis and design (OOAD) have emerged. Each methodology prescribes the use of certain tools for analysis and design. These tools differ across methodologies. Some methodologies for OOAD that have gained prominence are those described by James Odell and James Martin, Grady Booch, Yourdon and Coad, and Jacobson and Berard.
The identification of classes and attributes is no mean task. When working on a real life project, this step could take several weeks. As you proceed with OOD, you will realize that you may need to take another look at the list of classes that you have identified, and change it accordingly. Design is an iterative phase and there is always room for improvement.