Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!wdl1!pcg
From: pcg@wdl1.wdl.fac.com (Paul C George)
Newsgroups: comp.object
Subject: Re: OO vs. Information Engineering
Message-ID: <740001@wdl1.wdl.fac.com>
Date: 13 Sep 90 00:24:59 GMT
References: <21730@grebyn.com>
Lines: 37


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.