Using object-oriented analysis and design over traditional structured analysis and design

International Journal of Business Research, March, 2008 by Kenneth Pefkaros

* OOAD enables the standardization of objects which increases design understanding and decreases the risk associated with project development.

* Object decomposition enables the analyst to break down the problem into independent and manageable parts. Many times the work shifts from developing new code to bringing together existing objects in creative ways to solve the problem. Thus OOAD methodology cuts down development time and costs which will stimulate and induce market and competitive advantage. This results in a very flexible, easily changed and more maintainable system.

6.2 Disadvantages of OOAD

* In OOAD the initial designs for the system may be too simplified to be adequate.

* In OOAD there tends to be much more focus on code than in SSAD.

* In OOAD there is not as much emphasis on team work as in SSAD.

* In OOAD it is not an easy task to determine all the necessary classes and objects needed for the system.

* Many times object-oriented programming is used in conjunction with analyzing the various functions of the system; however, these function based methods are inappropriate in OOAD.

* Another major disadvantage of OOAD is the overemphasis of this object methodology in general where, in fact, another approach might be much better to use for the design and development of a system, depending on the particular circumstances.

* OOAD necessitates a new kind of project management which involves a different type of analysis from the traditional functional decomposition approach and structured programming methods. Consequently, for project development teams that have a long history of using the SSAD methodology, the transition to the OOAD methodology is extremely difficult and time consuming (Hantos, 2005).

* Finally, another shortcoming of the OOAD methodology is the concept of reuse. Reuse is considered one of the major benefits of this methodology and a reason for converting to OOAD. However, without an explicit reuse procedure in place many of the systems developed with this methodology do not lead to successful reuse on a large scale (Hantos, 2005).

7. CONCLUSION

In his paper Sumit Sircar (Sircar, Nerur, and Mahapatra, 2001) makes the following observation: "A recent survey of IS managers revealed that 39% of organizations have adopted OO technology in some form. Nonetheless, OO development methodologies are used in only 5% of IS projects are developed in OO methodologies (Glass, 1999)". For a specific application the first task is to decide which methodology is most appropriate for its development. Sometimes we may have to adapt different methodologies. Some guidelines might be that simple tasks may be better achieved by structured programming methods while the use of object-oriented methods might be better suited for higher levels of abstraction. This may also help with module design and problem decomposition. For situations in which the data is more likely to change than its functionality, objects would be more appropriate.

In order for companies to transition from the SSAD methodology to the OOAD methodology, they need to understand the substance of the change and the barriers that must be overcome; otherwise moving to this new methodology may end in failure. Consequently, for analysts and programmers to embrace this new methodology, they need to reorient their thinking from the functional perspective to the object perspective. More specifically for analysts and programmers with experience in the traditional methodology, training should be given to emphasize the modeling aspects of the methodology as opposed to learning the syntax and features of an object-oriented language. The transition from SSAD to OOAD can be made easier by supervised training and the use of object-oriented tools (Sircar, 2001).