Path: utzoo!utgpu!watmath!att!pacbell!ames!pasteur!ucbvax!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.software-eng Subject: Re: Attempts to connect SA/D and OOPS(2) Summary: Objects are not data, and data are not objects. Message-ID: <538@ajpo.sei.cmu.edu> Date: 7 Aug 89 22:23:06 GMT References: <8908071747.AA03249@mitre.arpa> Lines: 184 In article <8908071747.AA03249@mitre.arpa>,SBAILIN@NSSDCA.GSFC.NASA.GOV (Dick Botting) writes: > > There has been some recent discussion on the soft-eng mailing list > > The Communications of the ACM have published a paper > that has specific proposals for a modification to DFDs etc > that makes them more suitable for object-oriented programming. > > "An Object-Oriented Requirements Specification Method" > by Sidney C. Bailin > (CACM May 1989, Volume 32, Number 5, pp608-623) > > Abstract > "Analyzing requirements for Object Oriented Software is examined in an > alternative methodology from the more standard structred analysis approach. > Through parallel processes of decomposing objects and allocating functions, > the method is explained in detail". > > Review > This excelent paper makes a clear distinction between Structured Analysis(SA) > (organised by function) and an object oriented(OO) design (organised by data) ^^^^ Please, object-oriented systems do _not_ organize by data. Objects encapsulate: - knowledge of state information (which may deal with "data," but is more likely to be concerned with objects) - operations (and their associated methods) - [optionally] other objects, i.e., you may have: - homogeneous composite objects - heterogeneous composite objects - [optionally] exceptions - [optionally] constants - concepts To say that "objects are data" is like saying "people are houses." Houses may contain people, but people and houses are decidedly different. Some people begin to migrate away from a functional viewpoint, an towards an object-oriented viewpoint, by saying something equivalent to: "Systems are made up of objects and functions. Since functions do not appear to be objects, I guess data must be objects." The next stage is often the improved, but still not correct: "Objects are functions and data together." Sometimes you hear all kinds of strange things such as: "data objects," "function objects," and "controller objects." These are usually the result of people trying to reconcile their functional outlook with objects, e.g., since data is passive (inert) and objects are data (or highly data-like), objects must be passive -- but then, how does work get done? > and argues for the replacement of SA by OO at the requirements stage. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I very much agree. > As an example he shows that SA separates the reading, sorting, > and writing of some data into separate processes and a data store, > whereas an OO structure gathers these inside an object with > three actions and some data. This seems strange from an object-oriented point of view, because: - Reading is a composite operation involving several objects (the input object, the actual object being read, and at least one other object), see, e.g., the discussions on "objectification" on comp.lang.ada, comp.lang.c++, and others. - Sorting is also a composite operation, involving the object being sorted and the composite object which contains these objects, and operations from both classes. - The same is true for the writing operation. At best, you will have a massive amount of undesirable "object coupling." Reusability and software reliability will be diminished. > The 2 approaches have been recognised since Parnas's original papers on > decomposing programs into modules was published in the 60s and/or 70s. D.L. Parnas's paper ("On the Criteria To Be Used In Decomposing Systems Into Modules," Communications of the ACM, Vol. 5, No. 12, December 1972, pp. 1053-1058) Was a landmark paper which emphasized "information hiding." Information hiding is probably one of the most fundamental tenets of object-oriented thinking, e.g., "objects are black boxes." > The author presents and illustrates a step by step methodology for designing > systems. > He replaces Entity-Relationship-Attribute > (ERA) diagrams by simpler Entity-Relation-Diagram(ERD). > He also proposes changing DFDs to an EDFDs (Entity-Data-Flow-Diagrams) which > show the types of entity and how data flows between them. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Object-oriented systems don't have "data" flows. If the concept of something flowing is important to you, you can talk about "object flows," although this would seem strange to some object-oriented folks. > He makes clear the existance of strong rules of correspondence that will > hold in a correct OO design: > External entities --- Internal Objects > ERA Entity --- EDFD Entity > ERA Relation --- EDFD Flow > He has a program to check these rules. I appreciate the effort that has been expended, but I have to ask, "What does any of this have to do with an object-oriented approach?" > He notes (p619) that a common problem in Structured Analysis(SA) is naming > some processes since fuzzy names like "control", "manage", "handle", "monitor" > are discouraged or even verbotten. He claims that such "processes" are > actually entities in disguise. I strongly agree that names like "control", "manage", "handle", and "monitor" are fuzzy and should be discouraged. I would have a hard time agreeing with calling such "processes," "entities in disguise." They may be "large composite operations accomplished by a system of cooperating objects." > He argues that they should be shown as > objects that automatically and invisibly keep their state up to date. There is some truth to this. Somewhere within the "system of cooperating obejcts" there is very likely at least one "object with life," i.e., an object which is capable of spontaneously changing its own state. Objects with life (also known as "active objects," and "actor objects") do "automatically and invisibly" alter their state. ("Keeping the state up to date" is anohter discussion entirely.) > In my opinion this paper marks the conscious acceptance of ideas that > have been repressed by the hierachical and sequential paradigm that > has been the prevailing doctrine since the late 60s. Possibly we should > go further - subsume relations as entities (as in SSADM) and removing > ALL processes from DFDs. I find this a strange, but interesting analysis. I would dismiss the recommendation, and suggest that people consider adopting an object-oriented approach. > > This paper is required reading for anyone wanting to keep up > with Software Engineering. It is my opinion (and, yes, I know I'm biased) that this article will do more to confuse people attempting to understand what object-oriented thinking is all about, more than it will help them. I can offer a piece of advice to those attempting to understand what an object-oriented approach is. You will usually find two kinds of people: those who have developed a number of systems in a funtional decomposition manner, and those who have written code using a so-called object-oriented programming language. Some of these people actually understand what an object-oriented approach is all about. However, watch out for the following people: - The people with the functional decomposition background who often describe what their "fantasy" of an object-oriented system or approach might be. These people have usually not done much reading on the topic, and often provide their own interpretations of what object-oriented buzzwords mean. They tend to freely mix concepts from a number of different paradigms, e.g., data flow diagrams and objects. - People who have written code in an object-oriented programming language are often unable to separate concepts from implementations, e.g., they seem unable to discuss anything without talking about how it is done in programming language X. Some of these people claim that methodolgies are harmful, and that an object-oriented approach obviates the need for methodologies. > Dick Botting > CSUSB -- Ed Berard (301) 353-9652