(1) Low power consumption that avoids the use of a traditional clock. (2) Stack machine architecture - produces dense code. (3) Multiple stacks with shared hardware and compiler support.
Good software design is like good design in general: it maps the problem space to the solution space in a way which appears natural, given the right concepts presented in a specific context. I think that most of the advice you'll receive here will focus for the most part on techniques, not concepts, so I urge you to think about frameworks that group the techniques. Another word for this is architecture.
In my experience, most software is 95% glue and 5% wood. (i.e. 95% interfaces, and 5% algorithms). So suggestions such as modularity, encapsulation, information hiding, class hierarchies and so on are useful, as they serve to help us with the glue.
Good luck with your thesis. You might get more use from others if you ask them, not for solutions to your problem, but rather as for a characterization of the class of problems associated with software design itself.
No, programmers are not engineers. And the debate here has far-reaching implications, especially with respect to issues surrounding certification and liability.
Perhaps a good place to start is Mary Shaw's 1990 article "Prospects for an engineering discipline of software." published in IEEE software, Nov. 1990, pages 15-24. Here she looks at a definition of engineering and relates it to software development and deployment, so I think that it applies directly to programming. Dr. Shaw explains how a discipline develops from the craft/artisan stage, to a production discipline, and finally to a professional engineering discipline. She reviews the various kinds of software development (i.e. programming) and compares it or other forms of engineering, such as civil engineering for example.
If memory serves me right, the article showed that civil engineering could not come into being until there was a concerted effort to marry materials science with architectural principles. Prior to that, it was just talented artisans and craftsmen applying "best practices", comparing their work (i.e. benchmarking), and developing a large body of empirical evidence in an effort to do a better job next time around. Sound familiar?
Software engineering (and by implication, its lesser cousin, programming) doesn't stand up to this test - we lack the necessary base components (similar to what was required to legitimize civil engineering) to justify calling programming (and therefore what programmers do), engineering. For example, the industry practitioners lack the tools, training and desire to go about proving their software correct, although this seems to me to be a fairly basic engineering step. This by no means means that programming is a second-class activity, but should rather be an indication of where we are on the path to real engineering.
Another worthy reference is Edsger Dijkstra's article from his book "Selected Writings on Computing: A Personal Perspective" (Spinger Verlag publishers, circa 1982. The chapter in question called "Why is software so expensive" - an explanation to the hardware designer.
Slashdot Mirror
(1) Low power consumption that avoids the use of a traditional clock. (2) Stack machine architecture - produces dense code. (3) Multiple stacks with shared hardware and compiler support.
I hear that there are still some digits of pi that need finding...
In my experience, most software is 95% glue and 5% wood. (i.e. 95% interfaces, and 5% algorithms). So suggestions such as modularity, encapsulation, information hiding, class hierarchies and so on are useful, as they serve to help us with the glue.
Good luck with your thesis. You might get more use from others if you ask them, not for solutions to your problem, but rather as for a characterization of the class of problems associated with software design itself.
Perhaps a good place to start is Mary Shaw's 1990 article "Prospects for an engineering discipline of software." published in IEEE software, Nov. 1990, pages 15-24. Here she looks at a definition of engineering and relates it to software development and deployment, so I think that it applies directly to programming. Dr. Shaw explains how a discipline develops from the craft/artisan stage, to a production discipline, and finally to a professional engineering discipline. She reviews the various kinds of software development (i.e. programming) and compares it or other forms of engineering, such as civil engineering for example.
If memory serves me right, the article showed that civil engineering could not come into being until there was a concerted effort to marry materials science with architectural principles. Prior to that, it was just talented artisans and craftsmen applying "best practices", comparing their work (i.e. benchmarking), and developing a large body of empirical evidence in an effort to do a better job next time around. Sound familiar?
Software engineering (and by implication, its lesser cousin, programming) doesn't stand up to this test - we lack the necessary base components (similar to what was required to legitimize civil engineering) to justify calling programming (and therefore what programmers do), engineering. For example, the industry practitioners lack the tools, training and desire to go about proving their software correct, although this seems to me to be a fairly basic engineering step. This by no means means that programming is a second-class activity, but should rather be an indication of where we are on the path to real engineering. Another worthy reference is Edsger Dijkstra's article from his book "Selected Writings on Computing: A Personal Perspective" (Spinger Verlag publishers, circa 1982. The chapter in question called "Why is software so expensive" - an explanation to the hardware designer.