sdec@sei.cmu.edu (Susan Coddington) (06/22/89)
I am interested in any research and/or experience dealing with compatibility issues between structured methodologies (i.e. Structured Analysis and Structured Design) and Object Oriented Design. If you have any information on this subject, please respond via e-mail. Thanks! Susan Coddington -------------------------------------------------------------------------- Carnegie Mellon University, Mellon Institute - Computer Engineering Center 4616 Henry Street, Pittsburgh, PA 15221 (412) 268-6819 e-mail: sdec@sei.cmu.edu --------------------------------------------------------------------------
eberard@ajpo.sei.cmu.edu (Edward Berard) (06/22/89)
In article <9482@aw.sei.cmu.edu>, sdec@sei.cmu.edu (Susan Coddington) writes: > I am interested in any research and/or experience dealing with compatibility > issues between structured methodologies (i.e. Structured Analysis and > Structured Design) and Object Oriented Design. > > If you have any information on this subject, please respond via e-mail. > Functional decomposition approaches, such as SA/SD, localize information around functions. Object-oriented approaches, such as OOD, localize information around objects. Since objects are not functions, this results in quite a few nasty problems, e.g.: - A large project is initially partitioned along functional lines (e.g., CSCIs). Each of these large functional chunks is given to a separate team for further development using an object-oriented approach. Team A, for example, identifies a candidate object (X) with attributes A, B, and C. Team B identifies the same object (X), but with attributes B, D, and F. Each has an incomplete (and incompatible) view of the same object. This problem, unfortunately, will not be uncovered until integration, i.e., late in the development part of the life-cycle. - Even if the above problem is surmounted, there is still a large traceability problem. SA/SD meshes very nicely with functional requirements. However, due to localization incompatibilities, it is very difficult to trace functional requirements to object-oriented code. - The technical staff may be very familiar with functional decomposition, but very unfamiliar with object-oriented approaches. All goes well until the point where they are supposed to transition to the object-oriented approach. In the resulting confusion, many errors are introduced. Years ago, in the 1970s, structured approaches helped to bring (at least some) order out of the chaos of software development. Now there seems to be a "better" approach, i.e., an object-oriented approach. It is correct to assume that we can take some of the things we learned from structured approaches, and apply them to an object-oriented approach. The question is "which things?" Good candidates are: loose module coupling, high module cohesion, defensive programming, avoidance of decision splitting, and an overall systematic top-down approach. Not so good candidates are: data flow diagrams, structure charts, data dictionaries, and input-processing-output In addition to leaving some things behind, many new concepts must be introduced, including, reusability, classes, "objects with life," and systems of objects. At one time I used to say that OOD (ala Booch) required a "front end," i.e., something which preceded it in the life-cycle. I still say that. However, I, and others, know from unpleasant experience, that that precursor should be object-oriented (e.g., Object-Oriented Requirements Analysis (OORA)). Finally, a warning: watch out for well-intentioned people who try to sell you methodologies or CASE tools which claim to blend functional decomposition approaches with object-oriented approaches. The more you understand about object-orientation, the less you will see a need for such items. -- Ed Berard Berard Software Engineering, Inc. 18620 Mateney Road Germantown, Maryland 20874 Phone: (301) 353-9652