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: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public From: shapcott@wallaby.cig.mot.com (David B. Shapcott [C]) Subject: Re: What is wrong with OO ? Date: 1996/12/06 Message-ID: <589fu9$rkh@trotsky.cig.mot.com>#1/1 X-Deja-AN: 202885383 references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> organization: Cellular Infrastructure Group, Motorola newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng Date: 1996-12-06T00:00:00+00:00 List-Id: In article <32a5ceba.81462731@news.nstn.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. > >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. In bridge engineering, design and construction take place in different mediums, unlike software engineering. A software engineer designs and implements on the same medium, a computer, providing an opportunity to at least *partially* translate design information directly into implementation. Mechnical translation is less error prone than humans and far less labor intensive. The complete implementation cannot be synthesized mechanically, but such translation should be maximized. If the developers *depend* on design information, they will keep it up to date (they really have no choice). IME, flow control seems to be the correct level for partitioning. The concept you refer to is termed `round trip engineering' (RTE). Although trying to synthesize up-to-date design from the end product (i.e. reverse engineering) is the wrong way to achieve RTE. RTE works best when changing a design product is the only and *best* method for effecting change in the implementation. (This reverses the path of generation you propose.) Manual update and synchronization of design products with implementation never gets done. Never, IME. Reverse engineering only provides an up-to-date design product at the end of the implementation phase (IMO, synchronization should be continuous) -- although RE helps immensely when the developers are dealing with legacy or third party products. Some RTE schemes also suffer because the reverse engineering relies too heavily on the code generator. Even minor changes to the generated code can defeat reverse engineering. -- D. Brad Shapcott [C] Contractor, Motorola Cellular Infrastructure Group "Theory changes the reality it describes."