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.