Path: utzoo!utgpu!watmath!att!ucbvax!tut.cis.ohio-state.edu!bloom-beacon!MITRE.MITRE.ORG!soft-eng From: soft-eng@MITRE.MITRE.ORG (Alok C. Nigam) Newsgroups: comp.software-eng Subject: re: Attempts to connect SA/D and OOPS(2) Message-ID: <8908071747.AA03249@mitre.arpa> Date: 7 Aug 89 17:47:03 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 78 ------- Forwarded Message Received: from CALSTATE.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 2303; Thu, 03 Aug 89 16:15:37 EDT Received: by CCS.CSUSCC.CALSTATE.EDU from Mail by CSUMailer (1.3); Thu, 3 Aug 89 13:16:15 PDT Date: Thu, 03 Aug 89 13:15:42 PDT From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU Subject: Re: Attempts to connect SA/D and OOPS(2) To: soft-eng Cc: (Dick Botting), 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. (CACM May 1989, Volume 32, Number 5, pp608-623) "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) and argues for the replacement of SA by OO at the requirements stage. 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. The 2 approaches have been recognised since Parnas's original papers on decomposing programs into modules was published in the 60s and/or 70s. 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 dat flows between them. 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 Rel ation --- EDFD Flow He has a program to check these rules. 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. He argues that they should be shown as objects that automatically and invisibly keep their state up to date. 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. This paper is required reading for anyone wanting to keep up with Software Engineering. Dick Botting CSUSB ------- End of Forwarded Message