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: 109fba,7f8fc37d854731d6 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public From: Tim Ottinger Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/19 Message-ID: <3291ED22.7E08@csci.csc.com> X-Deja-AN: 197465259 references: <32813322.41C6@kyebek3.kjist.ac.kr> <55pqr5$136a@grimsel.zurich.ibm.com> <328109CD.6685@concentric.net> <55v177$ufo@grimsel.zurich.ibm.com> <3283BB94.2D82@concentric.net> <32875B03.3729@iconcomp.com> <328903AD.2786@concentric.net> <328B9122.5ECD@iconcomp.com> content-type: text/plain; charset=us-ascii organization: CSC mime-version: 1.0 reply-to: tottinge@csci.csc.com newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.smalltalk,comp.ai x-mailer: Mozilla 3.0 (WinNT; I) Date: 1996-11-19T00:00:00+00:00 List-Id: Bill Gooch wrote: > Well, I'm sorry that I apparently misinterpreted what you wrote. > I do believe that you know these things, and perhaps what we are > dealing with is a reflection of the fact that "design" is a very > broad term. I think of software designs in layers, from the most > abstract (related directly to the domain model) to concrete (the > closest to the implementation, and most language-specific). This > covers such a broad range that the relationship between layers at > each end is often lost, simply because there are so many refining > transformations in between, and methods don't support specifying > those refinements very clearly or completely. (This can change.) > In any case, I didn't say that the specification I referred to > was necessarily executable, nor usable to generate a program. > [Alan Lovejoy wrote] > > My thesis is that a design **methodology** should be able to handle designing > > a program regardless of language, although it will certainly need to take the > > differences between langauges into account. If I have to use a completely > > different methodology for each part of the system that is implemented in a > > different language, something is wrong. > > More or less, I agree. But in a practical sense, it isn't so > much the *methods* that are limited (with some exceptions), it > is the *notations* which don't span languages very well. The > need to be able to specify language-dependent aspects of design > when appropriate argues for multi-lingual, rather than language > independent, notation. IOW, perhaps you flip a language switch > when you're ready to deal with the more concrete design layers. > > Mapping designs between languages is even more problematic. If there's one thing that we should learn from Mr. Booch and the many others who've been with OO through the good, the bad, and the ugly projects, it's that we have to watch out for "the big project". The Big Project is the "clean-break from the past", "do it all", "no limits", type of project which typically fails. Typically, people believe that they can build a complex system, which works, from scratch. An end-all notation is a great idea, and if you can make a notation or method which is independent of all technologies but which uses every technology well, then I would love to see it. We have to face the "fact" that a design notation has to map cleanly into the engineering realm. If I could borrow the flimsy and much- touted "other fields" analogy, what good would a circuit diagramming notation do if it didn't map cleanly into manufacturing? In fact, if we don't consider manufacturing in our notation, we're probably making a big mistake. For instance, it's sometimes a mistake to use OO notation for a SA/SD software project, likewise it's frequently troublesome to use SA/SD design, and expect to manufacture an OO system easily from it. [ SOAP BOX WARNING: BEGINS NOW ] As much as we like to glorify our jobs, we analyse in order to design well, and design well so that we can build well, and we build well so that the software will run well. If my design is "independent of tech" that might be nice unto itself, but it pushes problems downstream. A lot of the analysis/design/code/test/release/revisit talks I hear are legitimate. You clearly should know what you want before you start, etc. Ad-hoc hacking can lead to some pretty ill-conceived systems, which act ill-conceived. Nobody wants that. On the other hand, a lot of talk seems to be trying to maintain a status quo for the "SE" career path (tester->coder->designer->analyst->manager). Let's face it, our separation of concerns is often separation of careers, and it exists to give us a promotion path with requisite pay raises and status. We're in an incremental world now. We iterate (okay, not all of us, SM). If we can't maintain our business organization and separation of roles and pay ranges in this world, is that a problem with the methods or the status quo? It's a hard call. It's bigger than this list, and can't be corrected by developers (though we can push for this). When we change our manufacturing methods, we must change the front-line skills, the tools (notation/language) and the organization of labor. We can surf, or we can get washed away. [SOAPBOX WARNING OVER] But the "ultimate" methodology should match the way we generate software. It should not be independent of it. It should not limit our abilities, and some tradeoff must be made from time to time. But our early analysis must eventually map onto hardware, or it wasn't a very useful part of the software development process (though it can be good for professional development ;-) ) -- Tim +------------------------------------------------------------------+ | Tell me again, *why* must we publish estimates before we | | gather requirements? | +------------------------------------------------------------------+ | Tim Ottinger, Sr Tech tottinge@csci.csc.com | | CSC Communications Industry Services 217-351-8508x2420 | | TRIS Division -- Cellular Billing and Support Fax 217-351-2640 | +------------------------------------------------------------------+