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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, 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: 10461e,7f8fc37d854731d6 X-Google-Attributes: gid10461e,public X-Google-Thread: 1108a1,7f8fc37d854731d6 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,7f8fc37d854731d6 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,7f8fc37d854731d6 X-Google-Attributes: gid103376,public From: Bill Gooch Subject: Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools) Date: 1996/11/14 Message-ID: <328B9122.5ECD@iconcomp.com>#1/1 X-Deja-AN: 196507014 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> x-rtcode: 8d8da879325644a03d8b8f93 content-type: text/plain; charset=us-ascii organization: Icon Computing mime-version: 1.0 reply-to: bill@iconcomp.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-14T00:00:00+00:00 List-Id: Alan Lovejoy wrote: > > Bill Gooch wrote: > > > > I'd like to hear more about how you think design can be done > > independent of language, and what such a "design" would look > > like.... I have a question: what do you call a > > program specification, not involving code, which does take > > these issues into account? > .... > Please believe that I am well aware of the fact that one absolutely must take the > idiosyncracies of the implementation technology (such as the programming language) > into account in desgining and coding a program. I'm sorry that so many people seem > to think I have suggested otherwise!... 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.) > Any "program specification" that could be used to actually execute a program, > or generate an executable program, is by definition a program text, and the notation > in which it is written is in effect a programming language.... "In effect," maybe it is - but consider that many CASE tools can generate executable, and by itself entirely useless, code from diagrams. Does this qualify the diagram notation as a "programming language?" Maybe some notations could be, but mostly I think they are not, because there are too many details they can't deal with effectively, if at all. In any case, I didn't say that the specification I referred to was necessarily executable, nor usable to generate a program. > 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. > Similarly, the design notation should be flexible enough to handle any and > all implementation languages. One may use different capabilities of the > notation and/or and specify different designs due to the intended target > language. OK, now it seems that we're on the same track... > But if the notation becomes completely worthless in the face of > an implementation language such as Self, perhaps there is something wrong with > the notation (and/or its underlying object metamodel) at a fundamental level. Perhaps; I'm not sure. I think the notations probably don't have more trouble with Self than some other languages, but the inter- pretation of the models (the meta-model) is very different. Sure, the designed structures are likely to be different also. The question in my mind is: is a prototype-based language really the same kind of animal as a class-based language? There must be limits on the domain our methods and notations are intended for, so where do we draw the line? > I am reacting to all the times I've seen people start their design process > by drawing class hierarchies.... I don't have too much trouble with that, as long as they've previously built some reasonable domain models which aren't concerned with implementation or class structure. It's a question of the starting point; if you understand the problem well enough, then solutions (including some of the class structure) may be fairly apparent. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm