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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: tbushell@fox.nstn.ns.ca (Tom Bushell) Subject: Re: What is wrong with OO ? Date: 1996/12/10 Message-ID: <32a972ad.42951429@news.nstn.ca>#1/1 X-Deja-AN: 203337536 references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> organization: Telekinetics newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng Date: 1996-12-10T00:00:00+00:00 List-Id: On 6 Dec 1996 07:08:24 GMT, harry@matilda.alt.net.au (Harry Protoolis) wrote: >IMHO, the trick with OO design is to do it *informally* most of the >time. What I mean by this is that you sketch out high level architecture >and analysis results as high level class diagrams and then give them to >the 'implementors' to design and code. > >The implementation team then does design as a series of informal >gatherings around a white board drawing state diagrams, detailed class >diagrams, object diagrams etc. You then photocopy and file the >whiteboard drawings and let the same group of people code from the >hand drawn design. Interesting! How many projects have you done this way? >I then quite often reverse-engineer the resulting code and call *that* >the formal system design. Can you give a rough estimate of the level of effort required to do this reverse engineering, as a percentage of total project effort? I assume you believe this is more cost effective than doing a more formal design up front. >My point is that the *design* and the *code* come into existance >together. To talk about the design becoming the code implies that it >exists before the code in some sense. Doesn't this contradict your previous description of the informal process you follow - the first "design" is the hand drawn sketches, which you then give to your coders, who will probably modify the design as they code. So it _does_ exist before the code. Some interesting semantic issues here - what is meant by "design" and "code"? The biggest distinction I tend to make is that a "design" artifact is at a higher level of abstraction, and not runnable; whereas "code" is runnable, and at the lowest level of abstraction. I may have to reconsider these definitions - they tend to blur together with the tools I'm proposing. >I think that a facinating tool would be a language sensitive drawing >tool in which you could switch your view between diagrams and code and >write 'code' in either view. This is very much as I envision it. What set me down this road of thought was my experience doing high level design for the Prograph class library, which was developed here in Nova Scotia. Prograph is a truly visual language *at the code level*, not just a GUI builder tacked onto an evolved version of FORTRAN, like VB/VC++/Delphi et al. This experience opened my eyes to what is possible. If the "code" is a "diagram", then the "design" is just another diagram at a higher level of abstraction, and it should be possible to move back and forth at will. Interestingly enough, another local person, Randy Giffen, has developed a browser that lets you take existing textual Smalltalk code and display it visually, and modify it or write new code totally within the visual environment. He says he hardly ever looks at the textual code any more - it's easier to write in the visual mode, and it's easier to understand existing code that way as well. Haven't had a chance to play with it yet, but the demo he gave was _very_ impressive! So, the pieces are all there, someone just has to put them together. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ----------------------------------------------------------