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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: peb@transcontech.co.uk ("Paul E. Bennett") Subject: Re: What is wrong with OO ? Date: 1996/12/14 Message-ID: <850522716snz@transcontech.co.uk> X-Deja-AN: 204115105 references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> <32A885CF.5530@csn.net> <32a98036.46416970@news.nstn.ca> <58lbbo$8kl@news.xmission.com> <32aefdb0..406273038@news.nstn.ca> x-mail2news-user: peb@transcontech.co.uk x-mail2news-path: tcontec.demon.co.uk organization: Transport Control Technology Ltd. reply-to: peb@transcontech.co.uk newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng Date: 1996-12-14T00:00:00+00:00 List-Id: In article <32aefdb0.406273038@news.nstn.ca> tbushell@fox.nstn.ns.ca "Tom Bushell" writes: > On 11 Dec 1996 03:55:36 GMT, tknarr@xmission.com ( Todd Knarr ) > wrote: > > >I think the problem with formal design goes right to your point #1, > >since in most other enginerring disciplines there *isn't* the strong > >dichotomy between design and implementation. > > Guess I wasn't clear about what I meant by "dichotomy". I was > referring to the fact that in current practice, the design and the > implementation are almost always distinct artifacts. The "design" is > a text, drawings, equations, or whatever. The "implementation" is > runnable code. Designs are models - static, abstract, incomplete - > not usable except as a precursor to implementation. Implementations > are dynamic, tangible, detailed - usable in the real world. > > If you accept this description, then there *is* a dichotomy in most > other enginering disciplines as well - the design for a car is the > blueprints, mockup, etc. The implementation is the drivable car. Perfect! I am glad that someone else seems to share my views on this. > This dichotomy may make sense for other engineering disciplines, who > must convert the design (which is information, or "bits", to use > Negroponte's term) into "atoms". But for software, it's all bits, > from design to implementtion! I'm merely speculating that the > dichotomy may only exist in software because the disciplines we're > thinking about emulating do it that way. I have no problem in supporting the dichotomy. To me a Software design is the source listing, which we will all pore over in review meetings and structured walkthroughs, and this is the detailed instructions which will enable someone to perform the implementation phase (like handing the schematics, PCB layouts, components lists and assembly instructions to the equipment manufacturer). > Perhaps this is a fundamental mistake, and we need to think of design > as an outline, or a scaffold, or a foundation, or whatever other good > analogies we can come up with, as opposed to a "model". Perhaps then > we will not face so much difficulty and resistance to formal design, > because it will become obvious that this is a worthwhile activity. Design exists at several levels in all engineering worlds. Concept Design, Prototype Design, Product Design, Industrial Design, Detail Design. Which level you need to be dealing with depends on how far thorugh your design lifecycle you are and what you are designing. > >All too often, though, the "systems analysts" hand me a design document > >which I'm supposed to implement which is exactly the programming > >equivalent of that 1000-foot single-span stone bridge. > > This is a very valid point, but in my mind a different issue (although > related). In other parts of this thread, we've been talking about the > "gap" between design and code - the sense that there's a big leap of > abstraction between current design models and implementable systems. > > I'm not really happy with the way I've explained this, and not even > sure I believe my own explanations, but will let it stand until > something better occurs to me. If someone wants a 1000-foot single-span stone bridge you can build a structure in exotic materials and stone clad it. As long as the customer has not visited the site during construction he will never know. I believe that we might call this "information hiding" in software. This thread has been a particularly long one for me to read today (as I have just returned to my system after a period away working) and all participants have contributed a mixture of interesting ideas and notions, some of which I can relate to easily. We are all going to need a whole range of tools and paradigms to enable us to grasp the essentials of what our customers want from the systems we build for them. One thing we should all learn from the disasters that have occurred in IS design is that failure of projects is a failure of the management of the project. The projects that are successful, despite their use of "bleeding edge" technology and very difficult concepts are those in which project management has been very effective in maintaining discipline and rigour of application in the teams. Choosing an appropriate "lifecycle" model and tools that enable the easy support of such a lifecycle would seem to be more worthy than arguing over which language a project should be done in. I would hope that we all agree that the language should suit the application area and use concepts natural to that domain (Application Specific Languages). The Critical Failure Factors for any project are: Hostile Culture (in the development or client organisation) Poor reporting structures [a most important issue to get right] Over commitment Political Pressures Under-estimated Complexity of problem domain (during initial phases) Poor Consultation Inappropriate Application (ie: Technical fix for management problem) High Staff Turnover Poor Staff Competency Poor Communication Inadequate Testing and Validation Inadequate User Training Insufficient Review Stages [the above list is taken "Software Failure: Management failure" by Stephen Flowers published by John Wiley and Sons ISBN 0-471-95113-7 and describes many IS systems which failed for one reason or another.] The question therefore is how do we avoid thos CFF's? You will notice that one item that does not appear in the list is Changing Requirements. This is a fact of life for engineers of all disciplines. Engineers have to be good at dealing with changes to the requirements and manage them in an orderly manner. Rather than spend money on CASE tools why not buy a decent Change Management Software Package. -- Paul E. Bennett Transport Control Technology Ltd. +44 (0)117-9499861 Going Forth Safely