This is the first in a series of articles on the relationship between the object-oriented approach to system development and the information engineering approach it appears to be replacing.
Look for additional articles in this series in future issues of The Data Administration Newsletter.
The world’s bookstores are now full of books concerned with “object-oriented analysis”. Is it possible that the world of object-orientation has completely changed the nature of systems analysis?
To listen to some of its aficionados, this must indeed be true. Information Engineering is passé, and has been completely replaced by object-oriented analysis. (1)
James Rumbaugh and his colleagues wrote one of the seminal books on analysis in the object-oriented world. (2) To their credit, they never used the expression “object-oriented analysis”. They
simply made analysis an important step in the object-oriented development process – as well they should have. The problem was that they then asserted that it was object-orientation that first
made analysis data-centric (3), which is not the case. (Entity modeling has been around since 1977.) This attitude has had the unfortunate effect of permitting the object-oriented world to assume
that any analysis that uses models of data structure is inherently “object-oriented”. This then forms the basis for asserting that the old way of doing things is now completely invalid.
For an entire body of knowledge that has developed over twenty years or more to be summarily overturned by a new approach seems unlikely. This has never happened before, and it is difficult to
believe that it has happened now.
More likely is the possibility that the object-oriented folks have added something to the body of knowledge. Perhaps, in addition to its contributions to design and programming, the object-oriented
world has something to contribute to the field of analysis. Or perhaps not.
While object-oriented analysis has been offered as a fundamentally new way of doing analysis, what is really new is that this version of analysis contains elements specifically oriented toward the
implementation of systems using object-oriented technology.
To understand why this is misguided, it is necessary to understand John Zachman’s “Framework for Information System Architecture”.
The Zachman Framework
By 1989, even though the industry was awash with methodologies, modeling notations, and different ways to “communicate” with each other, we in fact rarely communicated very well at all –
with each other or with our clients. In response, John Zachman came up with some important insights, and from them developed his “Framework for Information Systems Architecture” (4). Among other
things, Mr. Zachman realized that a source of our communications problems was that each of us views the problem of information system development from a quite different point of view. Mr.
Zachman’s recognition of these points of view was important, because it finally clarified why it is that we have such difficulty talking to each other. In particular, he identified six different
perspectives in any system development project:
- Scope – The understanding of why the organization exists, how it is like other organizations in the same industry, and what makes it distinctive.
-
Business owner’s view – This refers to the perspective not of the stockholders, but of the people who operate the business. This encompasses all the jargon of the
business, as well as an understanding of how everything actually works. -
Architect’s view – Recognition that there are fundamental, technologically-independent structures present, and representation of the business in terms of these
structures. -
Designer’s view – The application of technology to address any information system requirements discovered in the views above. The perspective here is
technological: relational data base systems, object orientation, network protocols, and so forth. -
Builder’s view – This is the view of the inside of the programs and technology. The builder knows the finer points of the programming language, or the
communications technology, or whatever. - Production view – The view of the completed system.
If two people are coming at the problem from different perspectives, their language and terms of reference will be different, and they will be working at cross purposes, unless they recognize the
differences in their points of view – and translate. With the translation it becomes clear to both why they believe what they do – and it becomes clear that, as long as they recognize
and respect each other’s positions, this doesn’t matter. Each has a different job to do, and each’s perspective is appropriate to the carrying out of those jobs.
Note that this is not an argument for the “waterfall approach” to developing systems. The waterfall addresses the perspectives in sequence: first, strategy addresses scope; then, analysis deals
with the business owner’s and architect’s views; later, design captures the designer’s view; and so forth. But this is not necessary. If you choose to start with design, you may do so. The
Framework simply tells you what it is you don’t know when you do that. That is, you don’t know the business owner’s perspective, so you will have to guess at what the system is to do. You don’t
know the architect’s perspective, so you will have to cobble the system together as best you can, without benefit of any understanding of fundamental structures.
Are you willing to risk the consequences of not knowing those things? If so, go right ahead.
If you decide to do a little bit of analysis, followed by a little bit of design, and then return to analysis, that’s fine. Again, it’s your choice. You can now understand the shortcuts you are
taking and the potential costs of those shortcuts. If you decide to do analysis and design at the same time, the Zachman view simply requires that you recognize you are dealing with two
perspectives at once, and you must be willing to accept the implications of this.
What OO Misses
The Zachman Framework now makes it possible to describe what is wrong with the object-oriented world’s approach to analysis. Specifically, object-oriented analysis begins with a cross between the
business owner’s view and the designer’s view, moves directly to the designer’s view, and never addresses the architect’s view at all.
Yes, Grady Booch specifically describes the importance of architecture, saying that “A system with sound architecture is one that has conceptual integrity and, as Brooks firmly states “conceptual
integrity is the most important consideration in system design.” (5) (6) It is also true that Mr. Rumbaugh and his colleagues devote a large part of their book to analysis, but if you look at the
details of how object-orientated analysis is too often carried out, you can see that architecture – based on the architecture of the enterprise to be served – gets pretty short shrift,
on both the function and data side of the effort.
Functions
A popular technique in the object-oriented world is “use cases”. These are represented as diagrams of specific anecdotes offered by people in the business being examined. They are supposed to
describe the specific activities carried out by an individual. As such they should be effective at capturing the business owner’s view.
As it happens, however, they don’t actually do that.
“A use case diagram provides a functional description of a system and its major processes and places a boundary on the problem to be solved. It also provides a graphic description of who
will use the system and what kinds of interactions they can expect to have with the system.” (7) [Emphasis added.]
Note that a use case describes a future “system”, not the existing enterprise. Moreover, it is about a future world when a new system will make all the business person’s problems magically
disappear. A use case does not actually describe the physical world presently experienced by the user. (“There are five copies of a purchase order and the gold one goes to accounting”.) Instead,
it describes a job in terms of the technology anticipated for the system (complete – in 1998 – with lap-top computers and web access (8). Rather than describing the current business, it
describes an imagined system – one that hasn’t even been designed yet.
It is the beginning of a user-interface design. That’s all.
As it happens, many of the business processes observed by the analyst are not really intended to carry out the functions of the business at all. They are only there to accommodate inadequacies in
current systems. Instead of trying to automate these processes, we should be trying to eliminate them. Instead of trying to do that, we should be asking, what is the business trying to accomplish
with these processes the analyst sees? What are the underlying functions to be carried out? What are the “essential” processes (without regard for the technology that might be used) required to
carry out the functions the business wants to do? How can technology bring us closer to providing the true functions of the business?
These questions are never asked.
Even if the use cases could be used to infer something about the current nature of business systems, developers then typically go from this supposedly business owner’s view directly to the
designer’s view. There is often no attempt to examine the set of use cases either to determine which should be automated or to identify general patterns of behavior or underlying functional
structures. Nor is there provision for analyzing a set of use cases to make sure that they neither overlap nor leave out important activities.
Data
If the object-oriented approach doesn’t come to grips with the underlying functions of an enterprise, what about its data? Unfortunately, to the extent that it is done, data
analysis typically only addresses the objects seen by the users, without trying to understand their inherent structure.
First of all, since object-oriented technology does not require normalization, this step is often skipped, precluding development of a sound understanding of the underlying structure of the data
involved.
When Dr. Codd invented the relational model, and with it “normalization”, the idea was that the normalization techniques were required to make relational databases work. With the appearance of
object-oriented database technology, presumably normalization is no longer required.
This would be true, except for the fact that the advent of normalization had a much more profound effect on the industry than the mere facilitation of relational databases: it has helped us
systematically to eliminate data redundancy, and, more importantly, to better understand the nature of data. Each datum in an enterprise is about something – and
only one thing. Our job as data analysts is to determine what that thing is. Moreover, there is only one datum that is that fact about that thing, and we must determine where to put that fact so it
can be found again.
If we don’t correctly identify the relationship between data and the things they describe, we haven’t done our job.
A second problem with the object-oriented approach to data is that it tends to identify object classes simply from the use cases, as the objects seen by the potential system users. This approach
fails to ask an important question: What are the fundamental things of significance to the business, of which the things most people see are but examples? The business objects described in
use cases are those that the individual sees in his own area of activity. Different individuals may be perceiving what are really the same objects, but with different names and characteristics.
Consider the following classes identified in use cases:
- Employees
- Customers
- Vendors
- Clients
- Departments
Are not all these things simply instances of “parties” (people and organizations) in different roles? Indeed will not many parties play several of these roles? Can an employee not also be a
customer? What about vendors who are also clients? Do we want to record each of these occurrences separately?
Going beyond the boundaries of the enterprise itself, are there not similarities between the fundamental structure of this enterprise and those of other enterprises in the same or different
industries?
Object-orientation is supposed to promote re-use: the place to start should be in the identification of standard entity/object models for standard business situations. (9)
In fairness, many object-oriented people have acknowledged the importance of understanding common structures while doing requirements analysis (10), and at least one book has now taken up the issue
of doing a proper conceptual architecture (11) (12), but these views are not reflected in a large part of the literature.
To summarize, in ignoring the architectural view, many object-oriented practitioners fail to ensure that they are addressing the entire enterprise. They fail to examine the organization as a whole
and to understand fundamental structures and processes – those which cut across the views of the individuals who run the business. There is no attempt to understand those structures which
will exist regardless of any technology employed to deal with them.
Yes, it seems to be true that object-oriented programming makes it easy to change a design when something turns out to be wrong. But this approach to analysis will guarantee that there are a lot
more wrong things to fix than would be the case if some architectural thought were given to the system before it was designed.
Conclusions
It has been difficult to write this article. The criticisms of object-oriented analysis presuppose that we know what object-oriented analysis is. As with any technique it is in fact
practiced very differently by different practitioners – many of whom disagree with each other on many points. Many who claim they are object-oriented are in fact following the best of
information engineering techniques. Indeed, many “information engineers” are guilty of analysis sins far more egregious than those presented here. Your author is the first to acknowledge both of
those points.
The problem is language. Our industry is highly susceptible to fads, especially in terminology. The fact of the matter is that the subject at hand is – as it has always been – how do we
do a better job of building systems? Each year people come up with new techniques to further the craft. Unfortunately, new sets of techniques invariably get packaged with a new name and are
presented as if they have completely overturned everything that went before. This is never true. The new techniques are always incremental additions to the body of knowledge and only that –
fancy names notwithstanding.
This is the problem with the way object-oriented analysis has been presented. Of course object-orientation has contributed greatly to the programmer’s art.
The assignment for requirements analysis, however, has not changed. It remains that of understanding an enterprise in technologically neutral terms. The objective is to determine the data,
function, and other requirements for information processing – expressed in terms that are both clear to the business customer of that processing, and which enable any technology to be applied
in addressing them. Nothing in the object-oriented arsenal of tools has changed that. Requirements analysis is fundamentally a dialogue between the system architect and the potential system user.
Many of its practitioners in fact do recognize that if object-oriented development is to succeed, its practitioners must acknowledge and adopt the valuable techniques which preceded the advent of
object-oriented programming. A proper business analysis is still required. Disciplined understanding of the nature of the data that describe objects remains important. We have known how to do these
things for a long time. We can’t afford to throw this knowledge out.
In short, there is no such thing as “object-oriented” analysis.
Copyright © 1998, Essential Strategies, Inc.
References:
(1) Oracle Education Services, “Oracle Education Mini-lesson: Object Database Designer for Oracle8 Objects”, Oracle Development Tools User Group, (Palm Springs, CA:1998), p. 3.
(2) James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, Object-oriented Modeling and Design, Prentice Hall (Englewood Cliffs, NJ:1991), PP. 153-156.
(3) Rumbaugh, et al., ibid, p. 146.
(4) Zachman, John, “A Framework for Information Systems Architecture”, IBM Systems Journal, Vol 26, No 3, 1987.
(5) F. Brooks, The Mythical Man Month”, Addison-Wesley, (Reading, MA:1975), p. 42.
(6) Grady Booch, Object-oriented Analysis and Design With Applications, The Benjamin/Cummings Publishing Company, Inc., (Redwood City, CA:1994), p. 230.
(7) Paul Harmon and Mark Watson, Understanding UML: The Developer’s Guide, Morgan Kaufmann Publishers, Inc., (San Francisco: 1998), p. 112.
(8) Paul Harmon and Mark Watson, op. cit. p. 116.
(9) See David Hay, Data Model Patterns: Conventions of Thought, Dorset House, (New York: 1997)
(10) Fowler, M, Analysis Patterns: Reusable Object Models, Addison-Wesley (Reading, MA:1997).
(11) James Rumbaugh, et al., op. cit.
(12) Craig Larman, Applying UML and Patterns: An Introduction to Object-oriented Analysis and Design, Prentice-Hall PTR (Upper Saddle River, NJ:1998).
