rick@tetrauk.UUCP (Rick Jones) (12/10/90)
In a recent article I wrote: >>... in my work the cleanest solution >>has often only come after several iterations and re-thinks, and in several >>cases what I've ended up doing is a lot different from what I expected to do >>when I started. Much lateral thinking is called for to get it right. To which Tom Meyer commented: >I certainly can see that. OOP is rather different is style and feel to the >other paradigms and it takes getting used to. There is a raging debate right >now about how to do object oriented design, capture the objects, etc. On this topic, I would be interested to hear the opinions of Eiffel users on it's capabilities as a DESIGN language. The whole issue of how to get object oriented design right is far from resolved, but it's already clear that it's a much more iterative process than "conventional" (what ever that means!) methods. One of the reasons I'm using Eiffel in my current project is that I find I can use it to design as I go. The style, as well as the simplicity of syntax, means that I can sketch classes in Eiffel, often leaving them incomplete until I've clarified other details which they depend on. If I were using say C++ (which is probably the only other practical alternative in my situation), I think I would have to represent the class design in some form which made the design itself clear, and then transfer it into code. Because I'm using a single language to do the design and implementation, I find that I can easily change the details when I discover that what looked right at an early stage turns out not to make such good sense once I get down to the nitty-gritty. I don't have the problem of going back to what I wrote for the design and changing it because what I've coded isn't what I thought I was going to do. The Eiffel code IS the design of the class. I don't in fact subscribe to the view that software design and coding are separable activities - the idea that software coding is somehow "manufacturing" a software product according to a design. Software manufacturing is copying disks! Designing and coding are all design in progressively greater detail. A programmer is a designer; if he's not, he's in the wrong job. Of course I'm not saying that the Eiffel code embodies the overall structural design of a complete system; you still need something else at a high-level, but this can generally stop at the block-diagram level of detail. It's at the individual class level that I find Eiffel is sufficient in itself. It is still marginally possible that for technical and/or political reasons our final product could end up being implemented in C++ or even C (I personally hope this doesn't have to happen). However, I will use Eiffel to produce at least a complete working prototype, and I think I would still continue to use it as a design language even if I had to do an actual implementation in something else. Do other Eiffel users find it valuable as a design aid, or do I just have an idiosyncratic way of doing things? If you use it the way I do, what changes would you make to increase its power as a DESIGN tool? Just interested! -- Rick Jones Tetra Ltd. Maidenhead, Was it something important? Maybe not Berks, UK What was it you wanted? Tell me again I forgot rick@tetrauk.uucp -- Bob Dylan
tynor@prism.gatech.EDU (Steve Tynor) (12/11/90)
In article <1050@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: ... >Do other Eiffel users find it valuable as a design aid, or do I just have an >idiosyncratic way of doing things? If you use it the way I do, what changes ... Absolutely! In fact it's one of the primary reasons I like Eiffel so much. The combination of deferred classes and assertions gives a very expressive design language - and like you say, the design _is_ the program. There's no conceptual (or even textual!) leap from the design to the implementation. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= C++: Just say no. Steve Tynor Georgia Tech Research Institute Artificial Intelligence Branch tynor@prism.gatech.edu
tom@eds.com (Tom H. Meyer) (12/12/90)
>On this topic, I would be interested to hear the opinions of Eiffel users on >it's capabilities as a DESIGN language. The whole issue of how to get object >oriented design right is far from resolved, but it's already clear that it's a >much more iterative process than "conventional" (what ever that means!) >methods. I personally have found that using a programming language (any of them) as a design language can lead to a somewhat insidious situation characterized by the old phrase, "When the only tool you got is a hammer, every problem looks like a nail." It is my belief that when you use a programming language as the design language, you bias your design to the capabilities of the language. I believe Dikstra said "One programs *into* a language, not in it." (emphasis mine) An acquintence of mine, Dar Scott, refined this to "One *should* program into a language, not in it." I believe this is closer to being accurate. Therefore, I generally shy away from using any programming language to do the abstract design. >One of the reasons I'm using Eiffel in my current project is that I find I can >use it to design as I go. The style, as well as the simplicity of syntax, >means that I can sketch classes in Eiffel, often leaving them incomplete until >I've clarified other details which they depend on. I will admit that, given that one is going to program in an object oriented style, my more abstract language often maps identically into Eiffel classes. I have also used Eiffel code literally in some correctness proofs. I believe this is a direct result of the clean, simple design of Eiffel which is something that I've always looked for in a programming language. >Because I'm using a single language to do the design and implementation, I find >that I can easily change the details when I discover that what looked right at >an early stage turns out not to make such good sense once I get down to the >nitty-gritty. I don't have the problem of going back to what I wrote for the >design and changing it because what I've coded isn't what I thought I was going >to do. The Eiffel code IS the design of the class. I think that perhaps the 'short' version of the classes is closer to the design. Detail omission (or hiding) seems to be a natural part of the design process. Focus on the big picture and all that. Thus, the actual implementation of the features isn't necesarily relevant to the overall design. >I don't in fact subscribe to the view that software design and coding are >separable activities - the idea that software coding is somehow "manufacturing" >a software product according to a design. Software manufacturing is copying >disks! Designing and coding are all design in progressively greater detail. A >programmer is a designer; if he's not, he's in the wrong job. Obviously, I disagree. Programming is the manifestation of the design. The design exists independant of its coding. For example, a single design can be implemented in many different languages. Given that all the implementations actually do the same thing (mod bugs, etc.), it's really still just one design, not many. If you feel coding and design are the same thing, would not that mean that each different implementation is a different design? >Of course I'm not saying that the Eiffel code embodies the overall structural >design of a complete system; you still need something else at a high-level, >but this can generally stop at the block-diagram level of detail. It's at the >individual class level that I find Eiffel is sufficient in itself. I would agree that, at some point, the abstraction difference between the design and the code is too small to want a different design language. Perhaps we are just arguing differing levels of abstraction or focus. This year's OOPSLA had quite a few papers and a panel on frameworks. Do you think Eiffel is a good framework language? Do you think frameworks are useful? The community was quite divided on the subject. Perhaps it's too early to say much about it. I don't have any personal experience using one or trying to adhere to one. Comments? tom meyer, EDS Research | If I don't see you in the future ...uunet!tantalum!tom | I'll see you in the pasture
rick@tetrauk.UUCP (Rick Jones) (12/24/90)
As a little Christmas reading (in case anyone's bored), this is a much belated
response to comments on an issue I raised around 2 weeks ago.
I originally wrote:
RJ>On this topic, I would be interested to hear the opinions of Eiffel users on
RJ>it's capabilities as a DESIGN language. The whole issue of how to get object
RJ>oriented design right is far from resolved, but it's already clear that it's a
RJ>much more iterative process than "conventional" (what ever that means!)
RJ>methods.
In article <4309@tantalum.UUCP> tom@ozmium.UUCP (Tom H. Meyer) writes:
TM>I personally have found that using a programming language (any of them) as a
TM>design language can lead to a somewhat insidious situation characterized by
TM>the old phrase, "When the only tool you got is a hammer, every problem
TM>looks like a nail." It is my belief that when you use a programming language
TM>as the design language, you bias your design to the capabilities of
TM>the language. [...] Therefore, I generally shy away from using any
TM>programming language to do the abstract design.
The problem I find here is that you cannot get very far from the _very_
abstract without considering the language. After all, the emergence of OOPLs
is radically influencing the process of design, since you cannot get the best
out of an OOPL unless your design is also object oriented. I feel the mistake
is to believe that languages fit neatly into categories - i.e. if a language is
"object oriented" you can use it to implement _any_ OO design. The reality is
that there are probably more variations in the inherent characteristics of all
the languages which claim to be object oriented than between all those that
don't. So if the difference between using any procedural language and any OO
language has a radical effect on your design thinking, so the choice of actual
language (especially in the OO arena) must have a serious impact on your
design.
I don't feel there is anything wrong in this. It is no different from other
longer established branches of engineering, where the choice of even raw
materials will affect the design. Take one of man's original engineering
discoveries, the wheel. The first wheel was probably made out of wood (with
due deference to the Flintstones!), and the design of wheels evolved to make
best use of that material. When the first metal wheels were built, they were
the same designs made in metal, but very quickly designs evolved which depended
on the use of metal - they could not be built in wood: try making a wooden
wire-spoked wheel, for example. Today, wheels are made using many different
engineering techniques, all of which are designed specifically to make the best
use of the particular raw materials chosen. It would in fact be considered bad
engineering not to do so. At the abstract level, though, they are all just
wheels.
One can see the same thing in architecture for example, where the best
architectural designs take into account from the beginning the materials and
methods of construction to be used. Taking this view of the world, the
examples become endless.
My general point is that there is an enormous difference between the abstract
design ("a wheel"), and the construction of some individual instance (the wheel
on my car), and that it is in this area that the real _engineering_ design is
required.
If in software we create a design which we consider is language independent,
and then take the view that all we need to do is "code it" in some language, we
will give that coding task to our programmers. If our view is also that coding
is not a design exercise and so don't expect programmers to be capable,
qualified, or experienced at it, we deserve all we get in terms of code
quality. We will have missed one of the most important steps, which is to
_engineer_ the design _into_ the chosen implementation language. This is much
more than just a job of coding.
TM>I will admit that, given that one is going to program in an object oriented
TM>style, my more abstract language often maps identically into Eiffel classes.
TM>I have also used Eiffel code literally in some correctness proofs. I believe
TM>this is a direct result of the clean, simple design of Eiffel which is
TM>something that I've always looked for in a programming language.
I suggest that this is because you are in fact thinking in terms of Eiffel in
your abstract design. Would your design map cleanly into another OO language,
and would that be the most _effective_ may of using that language? More
particularly, could you give your Eiffel-ish design to a _programmer_ of
another language knowing that he could do a good implementation directly?
Maybe you can, in which case I congratulate you on your design skills - you're
obviously doing it better than me!
RJ>Because I'm using a single language to do the design and implementation, I find
RJ>that I can easily change the details when I discover that what looked right at
RJ>an early stage turns out not to make such good sense once I get down to the
RJ>nitty-gritty.
TM>I think that perhaps the 'short' version of the classes is closer to the
TM>design. Detail omission (or hiding) seems to be a natural part of the
TM>design process. Focus on the big picture and all that. Thus, the actual
TM>implementation of the features isn't necesarily relevant to the overall design.
This is really what I am saying here. I don't try to finish a class straight
off, but I define the features & signatures, and at least start the code which
depends on and affects the relationships between classes. It is this last
activity where I find the details of the design can start to change in
unexpected ways, and makes the whole process an iterative one. This seems to
be because what appears as a sound group of classes at an abstract level
doesn't always fit the language's concept of a class. This is a difficult
problem to explain and quantify; I'm hoping to clarify my thoughts early next
year when I do the report on our prototype development - if I get any
illuminating insights I shall post them. I had considered that I was perhaps
approaching the original problem in the wrong way, but having looked back I
don't think that's the case.
RJ>I don't in fact subscribe to the view that software design and coding are
RJ>separable activities - the idea that software coding is somehow "manufacturing"
RJ>a software product according to a design. Software manufacturing is copying
RJ>disks! Designing and coding are all design in progressively greater detail. A
RJ>programmer is a designer; if he's not, he's in the wrong job.
TM>Obviously, I disagree. Programming is the manifestation of the design. The
TM>design exists independant of its coding. For example, a single design can
TM>be implemented in many different languages. Given that all the implementations
TM>actually do the same thing (mod bugs, etc.), it's really still just one
TM>design, not many. If you feel coding and design are the same thing, would
TM>not that mean that each different implementation is a different design?
What I've implied above is that if the implementation is a _good_ one, its
design must to some greater or lesser extent be language specific. This
follows from my assertion that it is a bad engineer who does not take account
of the inherent properties of the materials he is specifying in his design. In
software engineering, the programming language is I think the closest analogy
to "raw material".
TM>I would agree that, at some point, the abstraction difference between the
TM>design and the code is too small to want a different design language. Perhaps
TM>we are just arguing differing levels of abstraction or focus.
Perhaps!
As an overall observation, I wonder if the software business has gone a bit too
far in favour of implementation independence. This results from the same line
of thought which gave rise to the open systems concept, and the fear of being
"locked in" to something which is not future proof. It is of course essential
for software solutions to be independent of any specific hardware, and
preferably any specific operating system, but you have to hit common ground
somewhere. Programming languages are surely one of the key common components,
and one hallmark of a good language is that it _is_ implementation independent.
There should be no need to fear designing software specifically for one
language, given that the language itself is independent and portable.
TM>This year's OOPSLA had quite a few papers and a panel on frameworks.
TM>Do you think Eiffel is a good framework language? Do you think frameworks
TM>are useful? The community was quite divided on the subject. Perhaps it's
TM>too early to say much about it. I don't have any personal experience using
TM>one or trying to adhere to one.
This is not an area I have any experience in, and in fact I'm not really clear
what the definition of a framework language is. Perhaps you could enlighten
me? (I don't have the OOPSLA procedings)
In email Pat Podenski <podenski@sol.boeing.com> wrote:
PP>I don't currently use Eiffel (although I wish that I could). I read you
PP>article in comp.lang.eiffel regarding Eiffel as a design language. While
PP>I agree that Eiffel is much more readable and expressive than most
PP>languages and that there is an element of design in the iterative coding
PP>of programs, I wonder if that is always enough.
PP>There are a number of design methods (as well as analysis methods) popping
PP>up for object-oriented development. Examples include Shlaer/Mellor, Smith/
PP>Tockey (here at Boeing), Grady Booch, and a relative newcomer - Object-
PP>Oriented Modeling and Design (new book by James Rumbaugh, et al of
PP>General Electric R&D, Schenectady, New York).
PP>I am curious if you have heard of/or tried any of these.
I have to confess that I am not a devotee of formal methods - perhaps that's
something to do with the route I took into the software business, which was via
hardware engineering and systems programming, but I have always perceived the
need for structure in the solution to a problem. I have fully or partially
read some of the books you mention, and attended some seminars, but none of
them seemed to offer me any really constructive way to assist in solving
problems beyond my own intuitive approach. I think the major value of any of
these methods is in guiding the thought process for people who find it more
difficult to solve a problem in a structured way, and as a way of communicating
design information in an agreed format. As far as the latter problem is
concerned, I have been fortunate in always working in very small teams where
formality can sometimes be an obstacle, but given the direction of my current
work this is a bullet I think I am going to have to bite fairly soon!
On the subject of books, the one I found I could _not_ put down, and has
therefore of course influenced me considerably, is Bertrand Meyer's "Object
Oriented Software Construction" - that's why I'm now writing in this newsgroup!
PP>In the current
PP>scheme of things, it is seldom possible to find CASE tools that support
PP>OOA/OOD methods. And your comment about translating from "design" language
PP>to coding language is certainly a problem. The GOOD browser in Eiffel
PP>would seem a natural candidate to be extended into a more powerful tool
PP>for design and possibly analysis.
A browser can be a good (!) way to find out how an existing system works, and
also to find what library classes might be suitable candidates to help in
building a solution to a new problem, but I find it difficult to see how a
browser can help significantly in the development of a new design. By
definition, it offers an insight into what is already in existence, not what
has yet to be written.
PP>It is good to hear people say positive things about Eiffel. I think it
PP>is a very good language. I hope that it earns a place in the coming
PP>decade, because the alternatives don't seem very good at all (to me at
PP>least).
Join the club!
Since it will be after Christmas by the time anyone reads this, I will just
wish a Happy New Year to Eiffel-ites everywhere (I was going to say
"Eiffel-philes" but that seems an inexcusable assault on the English language!)
--
Rick Jones
Tetra Ltd. Maidenhead, Was it something important? Maybe not
Berks, UK What was it you wanted? Tell me again I forgot
rick@tetrauk.uucp -- Bob Dylan