Hello, One may identify a large number of abstraction levels in software systems (and software-hardware systems, for that matter). See how abstraction is described in http://www1.idc.ac.il/csd/book/index.htm [1] (Click on �Chapter 0�). Many, but certainly not all abstraction levels identified in the design process have a counterpart in among the implemented system�s abstraction levels. The above- mentioned book [1] describes only the latter, while this discussion thread refers to the former. Nevertheless, many of the underlying principles are the same. Not all possible abstraction levels are important. For a particular purpose, only a small subset of the abstraction levels may be of significance.
Chase (August 26) implicitly associates an abstraction level with the work products of the designer, and another one with the work product (program code) of the programmer. My two cents are that the work done at both abstraction levels is design. Design is a creative process where the designer chooses a particular solution for a set of requirements. Every abstraction level lays down the requirements for the next abstraction level. Every abstraction level is more specific than the one above it. I think that this agrees with Chase�s view, and places it in a formal framework. The difference between the designer-programmer model and the architect- bricklayer model is not in that the bricklayer makes no design decisions, but that the degrees of freedom available for him are by far less than available for the programmer. [1] �The Elements of Computing Systems� / Nisan & Schocken / Forthcoming in 2003 by MIT Press. ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ ---------------------------------------------------------------------- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
