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

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

* SSAD makes good use of it graphical analysis and tools such as DFD's.

* SSAD is a very well known and established methodology in the industry.

* SSAD has been around for a long time and consequently is a mature technique.

* SSAD allows for a means of requirements validation.

* Finally SSAD is relatively simple and easy to understand.

5.2 Disadvantages

* Since SSAD is process-oriented, it ignores the non-functional requirements.

* There is less direct management involvement in SSAD.

* Since SSAD is non-iterative like the waterfall model, so that requirements changes would mean restarting the entire process.

* In SSAD there is some but not enough user/analyst interaction.

* Except for the logical design and the DFD's, SSAD provides no other tools for communication with users, and therefore it is more difficult for users to measure progress.

* In SSAD it is more difficult to decide when to stop functional decomposition and to start building the system.

* SSAD does not always address the user's requirements.

* Finally, SSAD is not a good fit for object-oriented programming languages, as it was originally designed for structured programming languages and not object-oriented ones (Jadalowen, 2002).

6. ADVANTAGES AND DISADVANTAGES OF OOAD

The advantages and disadvantages of the Object-Oriented Analysis and Design methodology can be summarized as follows:

6.1 Advantages

* OOAD significantly simplifies the development of the system compared to SSAD.

* In comparison to SSAD, the development time, the level of organization, the robustness, and the code reuse are all greatly enhanced by the OOAD methodology (Sommerville, 2000).

* In OOAD there is no separation between the analysis and design phases, which improves communication between the users from beginning to end of project development.

* In OOAD analysts and programmers are not bound by the constraints of system implementation, so that they can formulate designs that conform to different execution environments.

* Since objects relate to entities (things) with which we commonly interact there is usually a clear mapping between the real-world entities and the corresponding objects in the system. This significantly improves understanding of the design (Sommerville, 2000).

* In OOAD the software is resilient to change, resulting in a higher level of confidence in the correctness of the software which helps to reduce the risks in developing complex systems (Booch, 2007).

* In OOAD, when developing objects with complex interactions, the analyst thinks on a different level of detail than is possible with structured code. In this case the analyst thinks about which attributes the object needs to know and how it will act on those attributes (Phelan, 2002).

* Since objects are independent encapsulations of data and methods, they are reusable and can be used in other projects in addition to the one for which they were originally created. This will reduce design, programming and validation costs.

* OOAD improves the quality of the system due to program reuse. Vivek Shah says in his paper that "If 90% of a new application consists of proven, existing components, then only the remaining 10% of the code has to be tested from scratch. That observation implies an order-of-magnitude reduction in defects" (Shah, Sivitanides and Martin, 1997).