From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!esl.ESL.COM!msg From: msg@esl.ESL.COM (Mark Gerhardt) Newsgroups: comp.lang.ada Subject: booch vs. buhr Message-ID: <8801301939.AA06188@esl.ESL.COM> Date: 30 Jan 88 18:39:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: There is a naive notion that a system can really be built by writing Ada specs first, and then the bodies. Often the requirements and early abstractions of an evolving system contain behavioral information. For example, an interval timout for a communications link shows up early in the system evolution process. The difference between Buhr and Booch is that Buhr includes some behavioral information from the body in the pictures. Selects and all their variants, may be drawn in Buhrgraphs. Booch, om the other hand, uses a methodology which hides this behavior within a package abstracti. The two approaches really differ about the underlying design methods which are implied by their use. Buhr encourages partitioning into cooperating processes and defines their cooperative semantics, while Booch encourages deferring the cooperating semantics into the bodies. Both are essentially static representations. What we REALLY need is sets of tools which operate on workstations and "animate" the intent of dynamics available within Ada. Elaboration, exception propagation, generic inst, and allocators are representable with an extension of the Buhr technique with animation support. In conversations with Buhr, I know that he is interested as well as I am in such extensions. Mark Gerhardt ESL, Inc. 495 Java Drive Sunnyvale, CA 94088-3510 (408)738-2888 x4556 arpa reply: esl!msg@ames.arpa or: msg@esl.esl.com