Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Exercise Solutions (Restricted)

Chapters 1 2 3 4 5 6 7 8 9 11 12

Chapter 4

Question 4.1
The chapter text has already mentioned the spreadsheet as an example of a tool that enables computers to solve problems without programs needing to be written. Describe a couple more situations where one would typically and wisely be able to use a tool rather than writing programs.

Can you think of any situations where one might be tempted to use an unwise choice of tool, and why?

Writing a GUI by hand would, today, typically be reserved for programs with very unusual needs and probably a very large numbers of users. Many, many systems would employ a GUI-building tool instead.

There are many data-processing situations where hand-writing code to understand (parse) linearly available data would be unnecessarily time-consuming and take an unnecessary risk that it wouldn't work properly. Lexer compilers and parser compilers would typically be a better route to take. [But that was mentioned in the book several times, so let's think of another example. JD]

With a standard database, a relational database for example, one would expect to use a report generator for typical reports. Hand-writing programs in general-purpose languages using API calls, or hand-writing SQL would typically be unnecessarily time-consuming and error-prone.

[And good GUI builders and report generators work in languages that are close to the problem, rather than a general-purposed programming language. A graphical user interface builder should probably work -- graphically. A specification of a report should look like a report. Just like a web page specification should look, at least a bit, like a web page. JD]

There are classic examples of tools that vendors try to sell us that, in many people's experience, look seductive but that don't bring benefit; indeed that sometimes reduce a project's chance of success. These kinds of things also figure in lists of "silver bullets". A general purpose code generator is the "tool" I have in mind. Application-specific code generators can work well, but I don't believe that a project, having failed to find a specific tool, and not able to summon up the will-power, budget, expertise, or whatever, to plan and write some good code, should turn to a general-purpose code generator, such as those that come as part of CASE tools, for example. I have similar doubts about the other-than-trivial benefits of reverse engineering tools.