Sign up

Using object-oriented analysis and design over traditional structured analysis and design.
Subject:
Object-oriented programming (Analysis)
System development (Analysis)
Author:
Pefkaros, Kenneth
Pub Date:
03/01/2008
Publication:
Name: International Journal of Business Research Publisher: International Academy of Business and Economics Audience: Academic Format: Magazine/Journal Subject: Business, international Copyright: COPYRIGHT 2008 International Academy of Business and Economics ISSN: 1555-1296
Issue:
Date: March, 2008 Source Volume: 8 Source Issue: 2
Topic:
Computer Subject: Distributed object technology; Object-oriented programming; Reusable code
Geographic:
Geographic Scope: United States Geographic Code: 1USA United States

Accession Number:
190463129
Full Text:
ABSTRACT

The existing methodology used primarily in industry today in building computer-based applications is known as structured analysis and design. This methodology came into existence as a result of the structured programming techniques introduced in the 1970's. This structured systems development methodology (SDM) has been fine-tuned and used for many years in the real world. However, during the last several years object-oriented languages have become increasingly more popular and more widely used in industrial organizations as well as university institutions. As this trend continued a methodology was developed to assist the programmer with the development of applications using object-oriented languages. This methodology has become known as object-oriented analysis and design (OOAD).The OOAD strategy approaches the problem from an object perspective as opposed to a functional perspective, which is the primary focus of the traditional structured development methodology. During the last few years the increasing use of OOAD over the traditional structured development methodology has spread significantly. As newer and more sophisticated object-oriented languages are created, there appears to be an even greater need for an object-oriented approach to develop business applications. However, does this need warrant greater use of this new methodology over the traditional one? We will compare the two methodologies and their advantages and disadvantages in order to address this problem.

Keywords: Systems Analysis and Design, Object-Oriented Analysis and Design, Waterfall Model, Systems Development Life Cycle, Object-Oriented Life Cycle, Class Diagrams, Data Flow Diagrams.

1. INTRODUCTION

After surveying many articles as well as the current and popular textbooks on Systems Analysis and Design which include but are not limited to those mentioned in the references (Rumbaugh, Blaha, Premerlani, Eddy and Lorensen, 1991; Embley, Kurtz and Woodfield, 1992; Gibson and Hughes, 1994, Norman, 1996; Dewitz, 1996; Bahrami, 1999; Dennis, Wixom and Tegarden, 2002; Brown, 2002; Satzinger, Jackson and Burd, 2005; Booch, 2007; Hoffer, George and Valacich, 2008;), the author has observed much discussion on the use of object-oriented analysis and design over the traditional structured systems analysis and design. While the use of OOAD methodology is justified in many cases, in some cases it may be inappropriate and we should consider the use of the traditional structured analysis methodology in the design and development of information systems. This paper attempts to clarify the use of these methodologies, to compare the advantages and disadvantages of each and to make recommendations.

2. BACKGROUND

A methodology is a procedure for resolving the problems of the current system or for building a new one. There are many methodologies for the design and development of information systems which include: Systems Development Life Cycle (SDLC), Rapid Application Development (RAD), Object-Oriented Analysis and Design, Prototyping and many others (Dennis, Wixom, Teagarden, 2002). The SDLC is more commonly known as Structured Systems Analysis & Design. Structured methodologies allow the analyst to break down complicated systems into smaller, clearly defined and more manageable parts. The structured systems development life cycle is a step by step approach that moves from one phase to another commonly known as the waterfall model because the development is always moving forward with no mechanism in place to go backward. In this model the systems development phases-analysis, design, and implementation are executed sequentially with some repetition between the phases, where the activities in each successive phase start with the completion of the activities in the prior phase.

The first object-oriented languages came into existence during the 1960's and 1970's with Simula and Smalltalk. However, it was not until several years later that the Object-Oriented Analysis and Design (OOAD) methodology came into being (Larman, 2004). First in 1982 Object-Oriented Design emerged as independent topic (G. Booch, 1982), and later in 1988 Object-Oriented Analysis was introduced by S. Shlaer and S. Mellor (1988) and S. Bailin (1988). Many different object-oriented analysis and design methods evolved since then by such well known individuals as J. Rumbaugh (1991), P. Coad and E. Yourdon (1991) and many others.

The OOAD methodology uses an object-oriented perspective rather than a functional perspective as in the SSAD methodology. An object is a person, place or thing initially drawn from the problem domain which has three aspects to it: what it knows (its identity and certain attributes), who it knows (relationships to other objects) and what it does (its methods it is responsible for performing on its data) (Norman, 1996). Object-oriented analysis is the process of developing an object-oriented model of the problem domain where the initial objects represent the entities and methods related to the problem that needs to be resolved. Object-oriented design is the process of developing an object-oriented model of the system necessary to meet the specified requirements. So in this methodology we think in terms of things (objects) rather than functions.

3. TRADITIONAL SYSTEMS ANALYSIS & DESIGN

The systems development life cycle (SDLC) or the structured systems analysis & design methodology (SSAD) is a framework of activities and tasks that need to be accomplished to develop an information system. This methodology as mentioned previously is called the waterfall model as each major phase of the methodology flows downward into the next phase (Wu and Wu, 1994). Consequently, this methodology is a strategy consisting of various techniques, tools, documentation and tasks that need to be integrated in order to develop the system. The SSAD is based on the concept of functional decomposition where the analyst breaks down the system into the basic processes that make it up and then breaks these down into smaller ones and so on until the analyst understands all the essential components of the system being investigated (Senn, 1989). The basic principles of the SSAD methodology can be summarized as follows:

* The first principle of SSAD is top down functional decomposition. Here the system is considered in its entirety where the analyst first tries to understand the key features of the system, ignoring the smaller details until later.

* Next the scope of system is defined where the physical details of the existing system are analyzed. The analyst focuses on two objectives: what the new system should do and how it should do it. (Davis, 1983).

* This methodology requires that the user be involved from the beginning to the end of project development. The analyst will meet with the user regularly to resolve problems and validate the user's needs. This also requires that the analyst possess highly developed communication skills (Bowman, 2004).

* The two primary concerns in developing an information system are processes and data which are modeled independently with this methodology. The processes are modeled by the data flow diagrams which illustrate the flow of data between processes and data stores and how it is altered as it moves through the system from source to destination. Data models are defined by entity-relationship diagrams (ERD's) which describe the data (entities) and the various associations among them.

* This principle of independently modeling the data and processes continues throughout the design phase. The schema for the conceptual database model is defined and the database is developed, normalized and populated with data during implementation. At the same time the process model is transformed into modules to be developed, and this phase also includes developing the detailed program logic. From the structure charts and program logic the program modules are then developed. Finally, to validate that the system meets the user's requirements, goals and objectives, we subject the system to various levels of testing.

4. OBJECT ORIENTED ANALYSIS & DESIGN

In his text John Satzinger et al (2005) describes the object methodology as follows: "The object-oriented approach to system development views an information system as a collection of interacting objects that work together to accomplish tasks. Conceptually there are no separate processes or programs; there are no separate data entities or files. The system in operation consists of objects. An object is a thing in the computer system that is capable of responding to messages." Consequently, the OOAD methodology can be broken up into two major areas:

* Object-oriented analysis. This is concerned with developing an object-oriented model of the problem (application) domain. These identified objects represent entities, and possess relationships and methods that are necessary for the problem to be resolved.

* Object-oriented design. This is concerned with developing an object-oriented model of the system necessary to implement the specified requirements. The analysts and programmers must think in terms of things (objects) rather than processes or functions.

The object model is based on principles including abstraction, encapsulation, modularity, hierarchy, concurrency, and persistence, and follows a repetitive and step by step approach to systems development (Rob, 2004). The major focus of the object model is object decomposition as opposed to functional decomposition, where a complex system is decomposed into several objects. An object-oriented system will consist of these various objects each of which will collaborate and cooperate with other objects to achieve specified tasks. Consequently, object decomposition allows the analyst to break down the problem into separate and more manageable parts. This is described in more detail as follows:

* As opposed to the structured systems development process, object-oriented development follows an iterative and incremental lifecycle. The four phases of the object-oriented lifecycle are inception, elaboration, construction, and transition. Consequently, an information system evolves by going through several iterations, each of which consists of all three primary tasks analysis, design, and construction. Requirements are defined by use cases which are object-oriented tools that describe scenarios of the interactions between the system and its users.

* These scenarios also help to identify objects, which model the data (attributes) and the corresponding processes (methods). Objects that represent the same entities are grouped together to form classes. Classes may be related to each other by different kinds of associations which may include inheritance and aggregation. We document these classes and their various relationships from the problem domain by class diagrams. These diagrams as well as the representations of the relationships among the classes are part of the Unified Modeling Language (UML) which has become the standard for the OOAD methodology (Podeswa, 2005).

* In the design phase these classes are expanded into design classes. In this phase the detailed requirements for each class are defined which includes its attributes and methods. The processes for the system are distributed among the objects as methods or services. Consequently, the objects must collaborate with one another in order to perform the various scenarios described by the use cases. We document these collaborations among the objects through the use of interaction diagrams, described by either sequence diagrams or collaboration diagrams. Then we build the information system by using combinations of classes that have been developed previously (reuse) and are available in a class library in addition to developing new ones using the specifications defined during the design phase. Finally we evaluate the resulting system by testing (Booch, 2005).

In summary there are three major components of the object-orient analysis and design methodology, and they are as follows:

1. Requirements Modeling: This describes who uses the system and how, consisting of actors, use cases and scenarios. Actors are people or entities that interact with the system. Use cases are defined to describe the expected behavior of the system. Scenarios are particular instances of these use cases that describe a specific requirement of the system.

2. Information Modeling: This describes the entities and relationships in the problem, consisting of objects, their attributes and the particular relationships among one another.

3. Life Cycle Modeling: This describes the way that an object responds to its environment, which is comprised of the various states to which an object can transition, the specific events that invoke these transitions between states and the specific activities that are associated with entering and leaving a particular state (Hoover and Olekshy, 2001).

The following table compares and summarizes these two methodologies (Jadalowen, 2002):

5. ADVANTAGES AND DISADVANTAGES OF SSAD

The advantages and disadvantages of the Structured Systems Analysis and Design methodology can be summarized as follows:

5.1 Advantages

* There are distinct milestones for SSAD which makes tracking easier for project management.

* Since SSAD is very visual, it makes it easier for users/programmers to understand.

* 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).

* 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).

Although the OOAD methodology provides many benefits, it does not resolve all the issues associated with the traditional SSAD methodology. There are still some shortcomings and weaknesses that need to be addressed which include: the amount of training needed, the time necessary to learn the new methodology, and the amount of money to invest in it. According to Glass (Glass, 2002) there is no guarantee that the adoption of a new technology will result in it being used effectively and efficiently. In addition, if the organization completely submerges itself in the new OOAD methodology, there can be costly and destructive results. Consequently, to take advantage of all the positive benefits that the new methodology offers, the organization needs to develop a carefully planned and gradual introduction of the methodology to all the system developers.

Before any effort is made to use the OOAD methodology as mentioned previously, it is imperative that the necessary education be provided in order to assure its success. The skills, knowledge and experience of the systems analyst and programmers who are indoctrinated in the traditional SSAD methodology can be enhanced by the new methods. Since changes to the basic structure of the OOAD methodology are stressful to manage, first attempts to use this methodology should be applied only to small scale and non critical applications. This will enable the company to receive immediate feedback and to have time to make any necessary modifications in the application of the OOAD methodology. Consequently, the benefits and advantages gained from using the new OOAD methodology can be much greater and more rewarding for the organization in the long term than using the traditional SSAD methodology (Glass, 2002).

REFERENCES:

Bahrami, A., Object-Oriented Systems Development, Irwin McGraw-Hill, Boston, Massachusetts, 1999.

Bailin, S., Remarks on Object-Oriented Requirements Specification, Computer Technology Associates, Laurel, MD, 1988.

Booch, G., "Object-Oriented Design", Ada Letters Volume 1 (3), 1982, 64-76.

Booch, G., Rumbaugh, J., and Jacobson, I., The Unified Modeling Language User Guide, 2nd ed., Addison-Wesley, Upper Saddle River, New Jersey, 2005.

Booch, G., Maksimchuk, R., Engle, M., Young, B., Conallen, J., Houston, K., Object-Oriented Analysis and Design with Applications, 3rd ed., Addison Wesley, Reading MA, 2007.

Bowman, Kevin, Systems Analysis: A Beginner's Guide, Palgrave Macmillan, Gordonsville, VA. 2004.

Brown, D., An Introduction to Object-Oriented Analysis, Objects and UML in Plain English, John Wiley and Sons, New York, New York, 2002.

Coad, P., and Yourdon, E., Object-Oriented Analysis, 2nd ed., Yourdon Press, Englewood Cliffs, New Jersey, 1991.

Davis, W., Systems Analysis and Design A Structured Approach, Addison-Wesley, Reading, Massachusetts, 1983.

Dennis, A., Wixom, B., and Tegarden, D., Systems Analysis and Design An Object-Oriented Approach with UML, John Wiley & sons, New York, New York, 2002.

Dewitz, S., Systems Analysis and Design and the Transition to Objects, Irwin McGraw-Hill, Boston, Massachusetts, 1996.

Embley, D., Kurtz, B., and Woodfield, S., Object-Oriented Systems Analysis A Model-Driven Approach, Yourdon Press Prentice Hall, Englewood Cliffs, New Jersey, 1992.

Gibson, M., and Hughes, C., Systems Analysis and Design: A Comprehensive Methodology with Case, Boyd and Fraser, Danvers, Massachusetts, 1994.

Glass, R.L., "A Snapshot of Systems Development Practice", IEEE Software, Vol. 16 (3), 1999, 110-112.

Glass, R.L., "The Naturalness of Object Orientation: Beating a Dead Horse?" IEEE Software, Vol. 19 (3), 2002, 103-104.

Hantos, P., Inherent Risks in Object-Oriented Development, February 2005; The Aerospace Corporation, www.stc.hill.af.mil.

Hoffer, J., George, J., and Valacich, J., Modern Systems Analysis and Design, 5th ed., Pearson Prentice Hall, Upper Saddle River, New Jersey, 2008.

Hoover, H., and Olekshy, T., Object-Oriented Analysis and Design a Practitioner's Approach, May 2001, Avra Software Lab Inc., www.avrasoft.com.

Jadalowen, I., Structured Analysis and Structured Design (SSAD) Summary, 2002; Software Engineering Research Network, pages.cpsc.ucalgary.ca.

Larman, C., Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd ed., Prentice Hall, Upper Saddle River, New Jersey, 2004.

Norman, R., Object-Oriented Systems Analysis and Design, Prentice Hall, Upper Saddle River, New Jersey, 1996.

Phelan, P., In What Way is Object-Oriented Methodology Better than Structured Methodology, November 2002; Expert Knowledgebase, www.techtarget.com.

Podeswa, H., B. O. O. M. Business Object-Oriented Modeling for Business Analysts, Course Technology, Boston, MA, 2005.

Rob, M., "Issues of Structured vs. Object-Oriented Methodology of Systems Analysis and Design", Issues in Information Systems, Volume V (1), 2004, 275-280.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W., Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, New Jersey, 1991.

Satzinger, J., Jackson, R., and Burd, S., Object-Oriented Analysis and Design with the Unified Process, Course Technology, Boston, Massachusetts, 2005.

Senn, J., Analysis and Design of Information Systems, McGraw-Hill, New York, New York, 1989.

Shah, V., Sivitanides, M., Martin, R., "Pitfalls of Object-Oriented Development", Business Quest A Journal of Applied Topics in Business and Economics, November 1997, www.westga.edu.

Shlaer, S., and Mellor, S., Object-Oriented Systems Analysis: Modeling the World in Data. Yourdon Press, Englewood Cliffs, New Jersey, 1988.

Sircar, S., Nerur, S., and Mahapatra, R., "Revolution or Evolution? A Comparison of Object-Oriented and Structured Systems Development Methods ", MIS Quarterly, Vol. 25 (4), 2001, 457-471.

Sommerville, I., Software Engineering, 6th ed. International Computer Science Series, Addison Wesley, Reading, MA, 2000.

Wu, S. and Wu, M., Systems Analysis and Design, Course Technology, Cambridge Massachusetts, 1994.

Dr. Kenneth Pefkaros earned his Ph.D. in applied mathematics from the University of Delaware in 1972. Currently he is a professor of management at the California State University, East Bay. His research includes operations research, decision support systems, and applied mathematics. He has published many texts and his papers have appeared in the Journal of Computer Information Systems, Review of Business Research, the California Journal of Operations Management and the Proceedings of the IABE.
COMPARISON BETWEEN THE TWO METHODOLGIES

Structured System Analysis &      Object Oriented Analysis & Design
Design

SSAD evolved from structured      OOAD evolved from object-
programming.                      oriented programming.

SSAD is process oriented;         OOAD is data oriented;
consequently the processes        consequently data is the
are the primary focus of          primary focus of the system.
the system.

SSAD breaks down the system       OOAD breaks down the system
through the use of data           through the use of Use Cases.
flow diagrams (DFD).

For SSAD the components of the    For OOAD the components of
system are derived from the       system are derived from the
DFD's.                            class diagrams and the
                                  Unified Modeling Language
                                  (UML). (Podeswa, 2005)

For SSAD there are definable      For OOAD there is an
steps: planning, analysis,        iterative and incremental
design, and implementation        approach involving continuous
from start to finish for          testing and refinement of the
the systems development           system from start to finish.
life cycle.

In SASD there is a separation     In OOAD there is encapsu-
of the systems data and           lation of the systems data
processes.                        and processes into objects.

Graphical design and tools are used to analyze and model the system
requirements.

For each methodology there is a step by step process for developing
the system.

Both techniques emphasize the documentation of the system and its
requirements.
Gale Copyright:
Copyright 2008 Gale, Cengage Learning. All rights reserved.