This paper addresses the issue of how two major analytical methodologies, structured analysis and object oriented analysis, differ. The approach taken is to briefly discuss the background of systems analysis, including the origins of the two techniques, followed by an overview of structured analysis and then object oriented analysis, after which a comparison is made and conclusions drawn.

The analysis phase of the software development cycle, variously known as systems analysis, requirements analysis or requirements engineering, lays the groundwork for all further system development. As put by Hsia, et. al., "The quality of a software product is only as good as the process that creates it." [HDK93. p.75] Yourdan asserts that it costs less to correct misunderstandings of requirements during analysis than to wait until final testing to discover them. [You86, p.133]

The general methodology of systems analysis actually predates computers by a few years, but neither is very old. Couger [Cou74, p.46] traces system analysis techniques back to the use of process flow charts to depict flow of materials by early industrial engineers such as Frederick W. Taylor and the Gilbreaths in the early 1900's. With the advent of computers, the technique was adapted to support computer programming. During the 1950's and 1960's additional techniques were also developed. [Cou74, pp.46-7]

Gane and Sarson [GS86, pp.5-8] point to a number of problems with these earlier techniques:

- There was no "vivid tangible model" to show users. (Indeed, Yourdan states that

"a central idea behind structured analysis is the use of graphs to communicate the system requirements to the end user." [You86, p.133])

- Descriptions of requirements in English are too verbose while suffering from an innate lack of precision. Gane and Sarson suggest that no one would build a house based solely on a narrative description.

- Flowcharts by their very structure force premature design decisions concerning the physical implementation and encourage excessive detail. Meanwhile they are generally meaningless to users.

- Methods in practice at that time provided no systematic way of recording user preferences and trade-offs.

Structured analysis was introduced as a way to correct some of these deficiencies.

The process of analysis is essentially the process of creating a model of the required system, i.e., creating a representation of a limited subset of relevant characteristics of the system which can be manipulated to test theories about the system's behavior. The more clearly the model is understood by all participants, the more likely the analyst will be able to construct a correct model. Structured analysis builds its model around system processes. Object oriented analysis builds its models around system objects. A key feature of both approaches is that the model constructed is a logical model - it describes what happens but not how. Once a correct logical model has been developed, a physical model can be designed to describe how the system will be implemented.

The programming concepts of class and object originated with SIMULA. The SIMULA programming language was specifically designed to create models of the physical world. The efficacy of this approach when applied to computer programming led to the development other object oriented languages. Object oriented programming has gained increasing acceptance over the last decade and a half. Object oriented analysis and design techniques came about as result of the recognition that structured techniques did not map well to emerging object oriented programming techniques. [Boo94, p.37]

Gane and Sarson define one of the goals of structured analysis as specifying the logical requirements of the system without imposing a specific physical implementation. [GS86, p.9] According to Mittra, "The structured method is decidedly superior to the conventional method because it completely specifies the logical system before going into the physical system. The customer is thereby made completely aware of the exact functional capabilities of the proposed system before any design work has actually taken place ." [Mit88, p.21]

Mittra [Mit88, p.20] distinguishes between structured analysis and the top-down method of analysis and design, but emphasizes that structured analysis uses a top-down approach, keeping the analysis and design phases strictly separate.

Mittra [Mit88, pp.25-6] suggests three laws of systems analysis:

According to Yourdan, "the term structured analysis also implies a certain methodological process: a step-by-step series of activities that, when finished will lead to a desired result - in this case, a complete specification of the user's requirements for a new system." [You86, p.133]

Gane and Sarson define these steps as: overall data flow diagram, detailed data flow diagram, immediate access analysis, content and structure of data flows, and external logic of processes. [GS86, p.34] Later Gane revised this list to: system wide data flow diagram, first-cut data model, entity-relationship analysis, normalized data model and revised data flow diagram based on entity-relationship analysis and normalized data model. [Gan89, pp.224-7] Yourdan has his own set of steps. [You86, p.136] [You89]

According to Gane and Sarson, "the data flow diagram at the logical level is the key tool for understanding and working with a system of any complexity". [GS86, p.37] "The simplicity of the DFD comes from the use of only four symbols to produce a picture of the underlying logical nature of any information system, at any desired level of detail." [Gan89, p.224]

The Data flow diagram is composed of the following elements [GS86, pp.38-46]:

There is no temporal dimension to the data flow diagram. [GS86, p.50]

The data flow diagram accomplishes three things: it sets a boundary on the system; it is nontechnical enough to demonstrate the logical system model to users; and it show the data, the processes and the relationship between the two. [Gan89, p.226]

Gane and Sarson's technique begins with a high-level data flow diagram that is considerably more detailed than the context diagram recommended by Yourdan. They state, "concentrate on getting everything down except errors, exceptions, and decisions." [GS86, p.51]

Once the overall data flow diagram is completed, each process is exploded into lower level processes and flows. At this point errors, exceptions, and decisions are considered. [GS86, p.52]

The notation in data flow diagrams varies by author. Gane and Sarson use rounded rectangles for processes, because "it is hard to get much legible writing inside a circle," [GS86, p.37] and their data flow lines tend to be straight, but processes can also be shown as circles or ovals and the lines as curves, giving the data flow diagram a very different cosmetic appearance without changing its inherent meaning. [You86, p.133]

The information in the data flow diagram should be recorded in a data dictionary. At this point, begin to define the data elements within the data flows and data stores. All of this is defined at the logical level. [GS86, pp.21-3]

Higher level processes are defined by exploding them into lower level processes. Lower level processes are then defined in terms of the "external logic", i.e., business policy, procedures or clerical rules. This can be portrayed using decision trees, decision tables, structured English or "tight English". [GS86, pp.24-6]

Once the structure of data flows has been developed in the data dictionary, something of the nature of the data stores can be determined: if you know what comes out of a data store in the data flows, you know what, at a minimum, must go into the store. The data stores can be simplified by normalization. [GS86, pp.169-200]

Four factors in responding to information requests must be considered [GS86, pp.204-5]:

While Gane and Sarson address costs and benefits as part of their structured systems development methodology, they don't consider it part of structured analysis. [GS86, pp.239-70] Mittra, on the other hand, does include cost/benefit analysis as part of the system analysis. [Mit88, p.95]

There is considerable diversity in the definitions applied to object oriented concepts. Booch describes an object as having state, behavior and identity. [Boo94, p.83] Rumbaugh, et. al., define the key properties as identity, classification, polymorphism and inheritance. [RBPEL91, p.1] When the meaning of all of this is sorted out, they are essentially saying the same thing. Objects are instances of a class, which is a group of objects having similar attributes (state) and behavior. Polymorphism simply means that each object defines how it responds to requests for certain behaviors, e.g., objects square and circle each respond to the request draw in a manner appropriate for that object. Inheritance means that there is a hierarchy of classes and objects in which each level receives from its parent attributes and behaviors. For example, square and circle each inherit the behavior draw from the class figure. [RBPEL91, p.2-3]

Booch defines a class as "a set of objects that share a common structure and a common behavior." [Boo94, p.103] Objects are concrete and classes are abstract, although in some circumstances a class can become an object. [Boo94, pp.103-4]

Attributes are data associated with an object which do not have independent meaning. [RBPEL91, p.23] The aggregation of attributes and their specific values define the state of an object. [Boo94, p.200]

An association is a relationship between two classes. [RBPEL91, p.27]

The characteristics of a class, its attributes and behavior, are inherited by classes and objects derived from that class. [RBPEL91, p.39]

An event is a relatively instantaneous occurence, such as mouse click. [RBPEL91, p.85]

Activities take time to complete and are associated with a state. [RBPEL91, p.92]

An action is a relatively instantaneous response to an event. For example, mouse click/select menu (where mouse click is the event and select menu is the action). [RBPEL91, pp.92-3]

State is determined by the values of attributes and links. [RBPEL91, p.87]

An operation is a behavior on the part of an object relative to another object. [RBPEL91, p.25]

Rumbaugh, et. al., suggest the following steps: problem statement, object model, dynamic model, functional model. However, they are insistent on the iterative nature of the process and recognize that there is no well marked line between analysis and design. [RBPEL91, pp.148-9]

The initial problem statement is provided by the customer. It is typically incomplete and mixes implementation details with true requirements. The analyst should rework the problem description with the requestor to eliminate unnecessary constraints on the design, clear up ambiguities, fill in missing details and highlight undesirable implications. It is the analyst's responsibility to get the problem statement correct: "If you do exactly what the customer asked for, but the result does not meet the customer's real needs, you will probably be blamed anyway." [RBPEL91, p.150-151]

The object model is a static view which is essentially an enhanced entity relationship diagram. It identifies classes, their associations, their operations, their attributes and inheritance. It is the framework upon which the other models are built.

In conjunction with the object model, a data dictionary should be prepared with definitions of all of the modeling entities. [RBPEL91, p.17,152-6, 267]

The system's time-dependent behavior is depicted by the dynamic model. The dynamic model consists of a state diagram for each class. The state diagram represents the "pattern of events, states, and state transitions for a given class". It captures the control structure of the model. [RBPEL91, pp.18,169-79]

The purpose of the functional model is to show how values are computed. It does this independent of sequencing, decisions and object structure. A data flow diagram is used for this purpose, with the processes corresponding to the activities on the state diagram and operations in the object model. [RBPEL91, pp.18, 179-85]

With no standard terminology, it should not be surprising that the model notation also varies. For instance, Rumbaugh, et. al., use rectangles for classes while Booch uses "clouds". Nevertheless, the content of Booch's class diagram closely parallels Rumbaugh's object model.

Comparison of structured analysis and object oriented analysis is difficult because they represent different ways of looking at a system - the system as activities or the system as things. Neither approach is correct and the other incorrect, they are just different. However, just as heliocentrism prevailed because it is easier to compute, one view of systems analysis may prevail because it better suits a greater class of problems. Booch represents that the object model better maps to realistic models of complex systems. And suggests that there are upper limits to the viability of structured programming in terms of code size. [Boo94, pp.9-21]

Despite their differences, there also similarities between the two methods:

- In spite of its emphasis on separation of analysis and design, Hsia, et. al., claim that structured analysis tends to lead to premature design. [HDK93, p.76]

- Structured analysis is centered on the functional view of the system, if most requirements changes are functional changes, they will present a greater challenge to a structured analysis. [RBPEL91, p.267-8]

- One characteristic of the structured analysis is the clearly defined system boundaries. This can be a disadvantage if it becomes necessary to extend the system. [RBPEL91, p.268]

- Structured analysis does not support object oriented programming well. [Boo94, p.161]

- Hsia, et. al., consider efficacy of object oriented analysis unproved for documenting system behavior. [HDK93, p.76]

- In spite of claims to the contrary concerning the clarity of object models, it seems likely that business managers will be more oriented to a process based paradigm than to an object based paradigm. And would therefore, understand better the models produced by structured analysis rather than object oriented analysis.

- In systems where process is clearly the predominant concern, structured analysis would be an equal if not superior approach. The issue becomes, how often this is the case. [RBPEL91, p.268]

Analysis is not intrinsically an easy task in any field, but software is deceptively facile in appearance and complex in reality. Booch presents evidence that software is innately much more complex than many physical systems. [Boo94, 5-9] Under these conditions, the use of tools and guidelines to aid in the analytical process can be invaluable, but cannot substitute for good hard thinking. Furthermore, one must be ever wary of mistaking the model for the reality. [Bee75, pp.399-416]

[Bee75] Beer, Stafford, 1975, Platform for Change, John wiley & Sons, London.

[Boo94] Booch, Grady, 1994, Object Oriented Analysis and Design with Applications, 2nd ed., The Benjamin/Cummings Publishing Company, Inc., Redwood City, CA.

[Cou74] Couger, J. Daniel 1974. "Evolution of Business System Analysis Techniques" in System Analysis Techniques, Couger, J. Daniel and Knapp, Robert W., ed. 1974, John Wiley & Sons, New York.

[GS86] Gane, Chris and Sarson, Trish, 1986, Structured Systems Analysis: tools and techniques, McDonnell Douglas Professional Services Company, St. Louis, MO.

[Gan89] Gane, Chris, 1989, "The Gane/Sarson Approach," Byte, April 1989, pp.224-227.

[HDK93] Hsia, Pei; Davis, Alan; and Kung, David, 1993, "Status Report: Requirements Engineering," IEEE Software 10:6, November 1993, pp.75-79.

[Mit88] Mittra, Sitansu S., 1988, Structured techniques of System Analysis, Design and Implementation, John Wiley & Sons, New York.

[RBPEL91] Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick and Lorensen, William, 1991, Object Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, NJ

[You86] Yourdan, Edward, 1986, "Whatever Happened to Structured Analysis?" Datamation, 1 June 1986, pp. 133-138.

[You89] Yourdan, Edward, 1989, "The Yourdan Approach," Byte, April 1989, pp. 227-230.