schultz@grebyn.com (Ronald Schultz) (08/30/90)
Object-Oriented Development appears to, after watching postings here, to be a niche software development technique, only suitable for real-time, graphics software, or operating system development. After watching for months, I have seen little to no posting as to how object-oriented development is in any way a complete lifecycle development approach for business systems development. My interest in this is from an MIS management perspective. Information Engineering (IE) (Finkelstein and Martin) is becoming the development methodology of choice for most organizations. Many of the Fortune 100 are spending millions on CASE tools in support of these methods. (In the latest issues of ComputerWorld, both Ford and GE have recently signed multimillion $$ agreements with CASE vendors for tools). Information Engineering experienced systems analysts command 5K to 15K higher salaries than their non-IE peers due to the number of companies trying to hire them. OOD, as it stands today in what I see in the trade press, on USENET, and in seminars, seems in no way as robust or as complete as IE. Tool support is diverse and complete for IE, from high level business systems planning support clear to automated code generation. The basic question is: How can an MIS manager in good concience recommend OOD for key, high visibility business systems again IE? As project manager for the IBM mainframe user's group project on Object-Oriented Development, I am constantly asked this question. While I may be a zealot for OO, I have serious doubts that OO will ever take hold in MIS against IE. Even the benefits of object-oriented programming may be soon passe against the code generation facilities of products like Knowledgeware's IEW and TI's IEF. And so I issue a challenge. In terms of a complete lifecycle methodology, from business systems planning through testing and maintenance, what does OO offer that is better than IE? Give me any reasons why a senior MIS manager should bet his job and that of his staff (and possibly his company - since many MIS systems are mission critical to an enterprise's survival (e.g. American Express)). Is the hype to OO merely a marketing promo for C++ and OODBMSs, or is there something substantial for us in MIS to deal with ? Thanx for listening Ron Schultz schultz@grebyn.com 614-759-3127
cox@stpstn.UUCP (Brad Cox) (09/03/90)
In article <21730@grebyn.com> schultz@grebyn.com (Ronald Schultz) writes: > >And so I issue a challenge. In terms of a complete lifecycle >methodology, from business systems planning through testing and >maintenance, what does OO offer that is better than IE? Give me >any reasons why a senior MIS manager should bet his job and that >of his staff (and possibly his company - since many MIS systems >are mission critical to an enterprise's survival (e.g. American >Express)). Is the hype to OO merely a marketing promo for C++ >and OODBMSs, or is there something substantial for us in MIS to >deal with ? > There absolutely is big news here of tremendous relevance to MIS and to IBM, but it has been obscured by all the hype to the effect that OO is only about glitzy new ways to build programming languages and databases; i.e. yet another in a long dismal chain of new *processes* for building code from scratch. Notice that the very term, 'object-oriented', implies reorienting so that not to continue seeking software's salvation in glitzy new *processes* (languages, methodologies, lifecycles, blah, blah) but instead by orienting instead on the *product*; the software itself. This is not a trival change, but a paradigm shift comparable to what Copernicus' did in shifting the center of the universe from the earth to the sun, and to what Ely Whitney did in shifting the center of manufacturing from cut-to-fit hand craftsmanship to a marketplace in interchangeable components. It is this broader change that is the long-term importance of OO, not the narrow whiz-bang technological focus that dominates OO discussion today. Two articles are being published this fall that go into this in detail. See the October issue of Byte magazine for "There is a silver bullet" which develops the Copernicus and Ely Whitney examples. Also see the November issue of IEEE Software for a deeper discussion of what I mean by the title "Planning the Software Industrial Revolution; The Impact of OO Technologies". -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482 -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
tom@ssd.csd.harris.com (Tom Horsley) (09/03/90)
I don't claim to have read all the books on software engineering ever
written, but I have read *a lot* of them. I kept reading them because I
hoped that someday one of them would make sense, but mostly they
continuously harp on the ``Lifecycle Model'' and ``Waterfall Diagrams''.
Every time I read one of these books I come away thinking "What a load of
<insert derogatory noun here>". Anyone who has ever been involved in
a large project to develop new software (not just re-write the same
old payroll system for a new client) knows that the so-called life
cycle model bears about as much relationship to what really goes on
in the software development process as Aristotle's description of
how to make mice (by leaving some cloth and rice in a pot outdoors)
bears to the actual life cycle of mice.
I would not go so far as to call OOD a "silver bullet", but I recently read
Grady Booch's new book "Object Oriented Design with Applications", and it is
the first software engineering book I have read that ever made sense or
seemed remotely relevant to the actual process of software development. It
is a very well written book that does not scream at you like some dedicated
OO fanatics do, but gives carefully reasoned arguments that clearly
demonstrate the fallacy of the so-called life cycle, and demonstrates the
superiority of OOD (without falling into the trap of claiming that OOD is
the total solution to all problems). This is a book that should be read by
anyone wondering why they should use OOD as well as OOD fanatics who think
that OOD will solve all problems, end war, and cure cancer.
--
======================================================================
domain: tahorsley@csd.harris.com USMail: Tom Horsley
uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle
Delray Beach, FL 33444
+==== Censorship is the only form of Obscenity ======================+
| (Wait, I forgot government tobacco subsidies...) |
+====================================================================+jimad@microsoft.UUCP (Jim ADCOCK) (09/05/90)
In article <TOM.90Sep3080218@hcx2.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) writes: |I would not go so far as to call OOD a "silver bullet", but I recently read |Grady Booch's new book "Object Oriented Design with Applications", and it is |the first software engineering book I have read that ever made sense or |seemed remotely relevant to the actual process of software development. I like the Booch book a lot. Another recent OOP survey book that I believe is very good is: Object Orientation: concepts, languages, databases, user interfaces Khoshafian & Abnous John Wiley & Sons 1990 ISBN 0-471-51802-6 ISBN 0-471-51802-8 [pbk] [Readers interested in C++ should be forwarned that both books get their C++ examples wrong.]
hkilov@corwin.CCS.Northeastern.EDU (hiam kilov) (09/11/90)
A frequently asked question:
My interest in this is from an MIS management perspective.
Information Engineering (IE) (Finkelstein and Martin) is becoming
the development methodology of choice for most organizations.
Many of the Fortune 100 are spending millions on CASE tools in
support of these methods. (In the latest issues of
ComputerWorld, both Ford and GE have recently signed multimillion
$$ agreements with CASE vendors for tools). Information
Engineering experienced systems analysts command 5K to 15K higher
salaries than their non-IE peers due to the number of companies
trying to hire them.
OOD, as it stands today in what I see in the trade press, on
USENET, and in seminars, seems in no way as robust or as complete
as IE. Tool support is diverse and complete for IE, from high
level business systems planning support clear to automated code
...
The answer is: "look at the keyword". The keyword in all of the above is
"tools". These silver bullets do not consider concepts, and -- evidently --
concepts are ahead of tools. Therefore there are problems with tools for o-o
development. However, it is possible to do o-o development using the best
tool in the world, i.e., your brains.
Look in the August issue (1990) of "Database programming and design". The
nice short article by W.Inmon (p.75-6) compares civil engineering and software
development. And I quote:
"Civil engineers recognize that tools are essential to do the job -- they
can't build the roads without bulldozers. They respect tools, but don't
make the mistake of thinking the tool is the solution. Information processing
professionals, however, continue to search for a panacea -- every time a new
tool appears in the marketplace, we hear that the solution has arrived..."
{Some good remarks about tool vendors deleted.}
As early as in 1976 E.W.Dijkstra has published a paper "The teaching of
programming, i.e., teaching of thinking". It would be nice not to forget at
least the title. And, of course, "programming" does not mean just "coding".
Happy programming!
<These opinions are my own and are not necessarily the opinions of Bellcore>
-Haim Kilov
haim@bcr.cc.bellcore.compcg@wdl1.wdl.fac.com (Paul C George) (09/13/90)
Most of the OOD approaches (ie booch, coad, mellor/schlaer) for requirements analysis are very similar to information engineering and the early 80's data driven design techniques. One studies the enterprise information to get a handle on how the business groups its information and what forms it takes. OO extends the concept of 'owning' information to encapsulating it in an object; that is a 'process' which provides externally accessable routines for getin at the information while retaining control. Further, it hides implementation details thus simplifing understanding. This maps well to the traditional data flow bubble process spec which defines the input and outputs of a process; as well as conventional documentation standards. It also provides a mechanism for implementing the data dictionary. Through the use of a type hierarchy you can specify the fields/attributes and entities in a way which is directly invokable in code, thus reducing multiple incarnations of the same record or field with different names. Rather than having to modify every module which your data dictionary says uses an item, you need only alter the type definition and recompile (presuming you implement in an object oriented language). The key savings is that you develop very modular code with few interdependancies. You can alter the implementation of an object without affecting anything that uses it. Only if you alter the interface are they affected. Admitedly, if you are implementing in COBOL the benifits will be less as you can't really evewn do structured programming using procedures. But 'conventional' languages like Pascal, Fortran, or C may support encapsulation of procedures or type definitions invocable via include or '.h' files. If you are stuck with COBOL than TI's IE tool set may be more usefull, but use of OO ideas such as types, inheratance, and information hiding may be usefull for defining your function hierarchies. In terms of OOSD, theis is essentially an extention of the Structure Chart for use with OO languages. If you use them, they may help. As a final comment, Object Orientation is not the holy grail. It presumes you have multiple pieces of software that communicate via messages. This may map well to event driven or distributed systems, but may not apply to complex state machines or batch processes. Some authors have distinguished between event driven, data driven (info content determines processing), and process driven systems. Other systems may in fact be composed of objects, or have multiple concurrent states and complex timing interactions between objects. Use a description technique most appropriate to the problem. Then select an inplementation design technique and language appropriate to the solution.