schultz@grebyn.com (Ronald) (01/12/90)
I just completed reading Peter Coad's and Ed Yourdon's Object-
Oriented Analysis (1990, Yourdon Press Computing Series, $29.95).
I am, to say the least, a bit disheartened with this text.
I have presented at MIS user's groups for a number of years. I
am, and I admit it, an ex-COBOL programmer (now a technical
director) who likes developing "routine" applications such as
management control and reporting, project tracking, purchasing,
and accounting. I have long since realized the limits of
functional decomposition approaches, and have explored the
object-oriented paradigm intensely for the past 2 years. I have
worked on trying to introduce OO concepts into the MIS community
for a number of years.
I am also a project manager for GUIDE International's (The IBM
Mainframe User's Group, with over 2200 member companies) Object-
Oriented Requirements Analysis Effort. In this capacity, I've
presented numerous sessions on OOA, OORA, and OO-Development.
Ed Berard has been out to speak on a number of occassions. His
input has always been well received.
This book is specifically targeted at "my" kind of people. Being
co-written by Ed Yourdon, I expect sales of this book to be
brisk. I have little doubt that I will get hundreds of questions
pertaining to Coad's approach presented in this book at the next
GUIDE conference in March.
-- The following text may be perceived as a flame. I do not
intend it to be, but for the sake of minimizing argument over my
intent
--- flame on, sort of -------
"Obect-Oriented Analysis" trivializes years of research done by
the AI, Ada, C++, Smalltalk, Eiffel, CLOS, ( fill-in-the-blank)
and software research communities. Take for example, page 16
" Though we cannot claim to have made a comprehensive survey
of classification theory and the organizational methods
proposed by philosophers and thinkers during the past three
thousand years, we did check out Encyclopedia Britannica to
read about how people organize problem space."
After reading hundreds of pages on problem space theories,
approaches and analysis techniques, I'm glad they consider
analysis important enough to trust to an Encyclopedia!
The primary bibliography consists of 6 books, 2 of which were
written by Peter Coad, and 13 articles. This in no way conveys
the depth of research and activity taking place in this area.
The authors justify this paucity by stating that "this book is
aimed at the practicing systems analyst, the person who has to
tackle real-world systems development projects every day. (4)".
The author's seem to imply (and I do not wish to place words in
their mouths, but) there really has not been a lot done in this
area, and that they, in their consulting, have "found the Way"
for MIS types to follow.
I have seen the ploy of "real analysts don't eat theory", (or
languages, or paradigms, or fill-in-the-blank) used countless
times before, but seldom so blatantly. "Managers, testers,
standards bearers, and users can read the book and expect to
profit from the overall approach to improving systems
analysis.(5)". I believe the authors intentionally over-simplify
OO concepts in order to simplify the marketing of their approach.
--- flame off ---
MIS: An Overview
To those of you not directly acquainted with the IBM MIS
community the following points are salient.
o MIS managers are highly conservative, pragmatic, and
bottom-line oriented.
EXAMPLE: Few MIS managers are willing to "bet the farm"
on a new technology. It took over 8 years from the time
commercials RDBMSs were available to the time they have
been accepted within the MIS community.
o After committing to a new technology, vested interest
precludes the introduction of a newer, 'new' technology.
EXAMPLE: MIS is just now buying CASE. An organization's
investment in CASE can exceed millions. IBM's new
AD/Cycle repository and tool kit (IBM's answer to CASE)
will exceed 2 million dollars just for the hardware and
software alone. Current CASE tools for MIS are primarily
structured analysis and design aids. After committing
to these kinds of dollars, few managers are willing to
reopen the question of CASE to their management. And
with good reason. The average life of a Corporate
Information Officer (CIO) is around 18 months. If it
works, (and it does not even have to work well), don't
muck with it.
o To most MIS managers, the solution to productivity rests
in tools.
Generally, IBM MIS shops are COBOL-based, on-line,
transaction-oriented, and moving to RDBMS and CASE.
Productivity improvements are being explored in:
a) generating COBOL code faster
b) generating database definitions faster
c) improving the performance of applications
d) reengineering COBOL code into 'better' COBOL
code, where better may mean more structured, better
documented, faster executing, or using a different
database.
MIS does not perceive any problems with the paradigms of
COBOL, structured analysis, E-R modeling, and the like.
In fact, many believe that if given the right tools,
education and training of programmers is not even
necessary. The tools will 'lead the way' to the
developing of reliable, high performing, and
requirements-satisfying applications.
Introducing Object-Oriented concepts to the MIS community is
a true challenge. MIS considers that a) functional
decomposition and procedural languages are good, b) that the
answer lies in tools, and c) problems with reliability,
reusability, and documentation are all tool related problems,
and can be resolved with CASE. Software reusability and
maintainability are seldom an issue. Why maintain, if product
X can reengineer my code ?.
Object-Oriented is a paradigm, and in presenting it to a naive
community (I have heard MIS referred to as a virgin community,
but composed mostly of 85 year-old virgins), the issues of
paradigm shift must at least be discussed. Many learned that
getting the true value of Ada was more than simply learning
a new language syntax. Object-Oriented is more than reading
one text and using the defined toolkit.
There is hope. Some MIS are realizing that there are other
ways of developing software. Some are exploring these
concepts, and even piloting small efforts, much as they did
with RDBMS in the early 80's, and 4th Generation languages in
the mid to late 70's. MIS is ready to listen about and try
Object-Oriented. But is this text representative of "Object-
Oriented".
Review Comments:
I believe this book panders to MIS in at least 3 instances.
The first is the small bibliography. This seems to imply that
learning about OOA is easy and quick to learn. Read half a
dozen books, and voila, almost instant OO Analyst.
The second is the line on page 31 that
" OOA builds upon the best concepts from Information
Modeling (entity-relationship diagrams and sematic data
models) and the best concepts from Object_oriented
Programming Languages."
To me this implies that OOA is an evolutionary step from
current software development. While the evolution-
vs.revolution debate can go on forever, at the very least Coad
ignores the significant training and educational efforts
associated with OOA. In another example, the authors utilize
a data flow diagram segment (pg. 145) to help define their
object "services" ( their term for method, or operation).
Again, implying that evolution is the key to OO.
The third instance is their "CardCASE" product (pg. 162). "It
seems like a very promising - and extremely inexpensive - tool
for object-oriented development. We use ordinary 3" by 5"
index cards." To the MIS community this says, why buy
analysis CASE tools when all you need is OOA and 79 cents
worth of index cards. I have liitle doubt this will sell well
to cost-conscious MIS.
Some Problem Details:
-- Problem 1 --
Throughout the book their exists a confusion about instances,
objects, and classes. In fact, the term 'classes' does not even
have an index entry. On page 7, the authors
"expect to further develop OOA over time. Some of the issues
under consideration include the following: ....
7. Adding and distinguishing between Objects and Collections
of Objects."
It is apparent that the authors do not fully understand the
concepts of objects, classes, and instances. Throughout the text
confusion reigns about these concepts.
Another point of confusion: In Chapter 6 - DEFINING ATTRIBUTES
the authors define attributes as "data elements used to describe
an instance of an Object or Classification Structure. (pg. 100)".
Yet in this section they discuss how to relate instances through
"instance connections (106)". "An instance connection is a
mapping from the one instance to another. (106)". The approach
appears directly mapped from some form of extended Entity-
Relationship modeling. I do not understand how the authors
consider this interconnection a function of "defining
attributes".
In addition, while I have nothing against E-R modeling, Coad's
approach promotes a high degree of object-coupling. Object
coupling dramatically decreases the reusability of any developed
objects, since every object is compelled to know about its
relationship with other objects, and this knowledge must be
incorporated into the object itself. The instance connections
could easily be implemented as operations/methods/services in
other, more application specific subsysytem or system objects.
This would remove the object-coupling present in this approach,
and improve the reusability of the non-application specific
objects.
-- Problem 2 --
In Chapter 7 DEFINING SERVICES the author's define "a Service is
the processing to be performed upon the receipt of a message.(pg.
135)". In identifying messages, the authors recommend using
State-Event-Response as a strategy on page 134. This involves
defining the major system states, and "For each state, list the
external events and required responses.". They then use this
approach to identify states of an aircraft in an air traffic
control system, and a sensor in a sensor system. Yet throughout
the book a title registration system, used in other examples in
this book, is notably absent from this example. They seem to
imply that in an "MIS" kind of system this approach is not
appropriate. Yet what about such vehicle states as
"unregistered", "new", "registered", "untitled", and "titled" for
example. Using states and state transition diagrams is extremely
appropriate to identifying methods/services in an MIS system.
In the DEFINING SERVICES chapter the authors take a "I can use
what I already have, and minimize what I need to learn" sleight
of hand by stating that objects interact through "Message
Connections (pg. 135)" where a "Message Connection combines
event-response and data flow perspectives; ... (pg. 135)". Why
is it necessary to constantly refer to old techniques that may
or may not be appropriate in defining OOA unless the author's are
trying to state the all currenly available structured analysis
tools are useful in their Object-Oriented Analysis Approach.
-- Problem 3 and Final Problem --
"Object-Oriented Analysis" by Peter Coad and Ed Yourdon, IMHO,
will significantly confuse the MIS population in the application
and benefit of Object-Oriented concepts. It avoids any
discussion of paradigm shifts, training, education, or impact on
the development lifecycle. It basically conveys the thought that
OO is an incremental (and some may argue very small improvement)
over current structured techniques. It argues that the currently
available structured analysis tools are easily migrated to this
approach. I believe that systems designed using the concepts in
this text will suffer from the same problems in functionally
decomposed systems, that is:
o No or minimal reusability due to object-blindness
and object-coupling present
o Difficulty in testing due to the object coupling
present
just to name two.
I presented sessions at GUIDE two years ago on "Object-Oriented
Data-Driven Development", or what I coined O-Squared D-Cubed
(O2D3). I long since discarded that approach due to the many
problems it generated. What I see in OOA is virtually the same
concept, that is an incremental improvement to existing
techniques. Such a concept sells well, but is it valid ? I
believe I now know better.
----------------------------- Conclusion ----------------------
--
The above is not to be considered a flame, while by many of you
it may be perceived as such. I must admit, the book, is well
organized, written in a light, easily readable style, and is
loaded with examples. I wish competing texts were available in
the same style.
My complaint is the text is misleading, trivializes the object-
oriented paradigm, negates many of the benefits that can be
garnered by users of OOA, and is IMHO going to jeopardize MIS's
successful exploration of this exciting technology.
I would appreciate any feedback or comments.
---------------------------------------------------------------
-
Ron Schultz
schultz@grebyn.com
Phone 614-841-1110
FAX 614-841-1169
Mail Address:
5634 Claire Court
Dublin, Ohio 43107
---------------------------------------------------------------
-