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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: marnix@worldonline.nl (Marnix Klooster) Subject: Re: What is wrong with OO ? Date: 1996/12/05 Message-ID: <32a69c3d.8260500@news.worldonline.nl>#1/1 X-Deja-AN: 202470540 references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> organization: World Online newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1996-12-05T00:00:00+00:00 List-Id: tbushell@fox.nstn.ns.ca (Tom Bushell) wrote: > It is my growing opinion that this is a fundamental problem with all > "formal" design methods, not just OO design. The effort involved in > doing the design is as great or greater than doing the construction > (coding). Contrast this with doing the blueprints for a bridge - the > design effort is orders of magnitude cheaper than the construction. > (Or so I believe - a civil engineer might correct me on this). Also, > the OO design models I've studied don't seem to be very good maps of > actual real world systems - there seems to be a big gap between high > level architecture and running code. I believe there should be a > fairly smooth continuim from high level to low level of detail. Couldn't agree with you more. > I'm starting to believe that design and code don't make sense as > separate entities - the design should _become_ the code - the design > documents for an implemented system are used as the foundation of the > code, and then regenerated from the code. Major benefits would be > that design work would not be discarded because it was too difficult > to bring it up to date with reality. Therefore, the design should > never get out of synch. This a similar idea to reverse engineering, > but not identical. One approach in the direction you sketch is the formal method called the "refinement calculus". Essentially, a (formal) specification is considered to be a very high-level non-executable program, and programming tries to `refine' that program to an equivalent one that is executable. The refinement calculus gives formal proof rules with which refinements can be proven correct. Therefore, the side-effect of developing a program this way is a proof that it meets its specification. In other words, we have a `provably correct program.' > If anyone has knows of tools that would facilitate this approach, I'd > certainly be interested. I've done some very simple prototypes, and > hope to work on the idea in future (when I have more time - Hah!). Because of the emphasis on proof, the refinement calculus requires more mathematical skills of the programmer than other methods. Also, for larger programs having some kind of proof support tool is a necessity. Finally, it often happens that the specification must be changed halfway. With proper tool support it should be easy to check which refinements still hold, and which don't. Such tools are under development; try the "Formal methods" web page at http://www.comlab.ox.ac.uk/archive/formal-methods.html If you want to know more on the refinement calculus, you could begin with Carroll Morgan, "Programming from Specifications", Second Edition, Prentice-Hall, 1994, ISBN 0-13-123274-6. > -Tom Groetjes, <>< Marnix -- Marnix Klooster | If you reply to this post, marnix@worldonline.nl | please send me an e-mail copy.