Instructor's Manual for

M.B. Feldman and E.B. Koffman, Ada 95 Problem Solving and Program Design, 3rd edition. Copyright 1999, Addison-Wesley Publishing Company. All Rights Reserved

Questions and comments to mfeldman@seas.gwu.edu


Chapter 4 Problem Solving and Using Packages

last revised March 1999

Chapter Objectives

The student will

  1. learn the stepwise-refinement approach to problem-solving, as illustrated by a few simple everyday examples and programs
  2. learn how to develop a program from its documentation, using comments to represent major algorithm steps
  3. be introduced to the concepts, but not the programming details, of structured programming
  4. be introduced to enumeration types and their input/output library
  5. be introduced to the use of packages, including Ada's predefined Calendar package and a screen-control package provided with this book

New Terms

Section 4.1

subtypes

compatibility rules

Section 4.2

stepwise refinement

program documentation

Section 4.4

enumeration type

enumeration literal

attribute query

enumeration I/O

Section 4.6

Calendar package

function call

structure chart

 

Section 4.7

package specification

package body

precondition

postcondition

Notes and Suggestions

It is important to reinforce continually the systematic refinement approach to solving problems. Students may feel that the approach is overkill when applied to very small problems; motivate them with the rewards they will reap later as the problems grow more complex. Some teachers find it useful to require students to hand in the design part of a project--at least the data requirements and major algorithm steps--earlier than the program itself; this motivates students to do things in the right order.

This chapter also introduces the students to packages that are not part of the standard libraries. This is part of the book's overall philosophy that "system structures"--those governing inter-module communication and the construction of systems of programs--should be taught not as an advanced topic but as something fundamental, to be introduced very early and "scaled up" at the same rate as control structures and data structures.

Packages are therefore not to be seen as "magic" or "beyond the scope of this book." There are simple, easy-to-understand packages, and complex, sophisticated ones. The packages in this book are scaled up such that students can understand their implementations at roughly the same time--no more than a few chapters later--as they understand and use the interfaces and clients.

In this chapter, students learn to use packages; starting with Chapter 5, they learn to write them.

Section 4.1

This book makes heavy use of subtypes to ensure that variables are always declared with ranges that suit the needs of the application. Insist that students use them in their projects.

The idea of subtypes is alien to those with experience in C or Fortran. Motivate subtypes with an explanation that subtypes actually save programmers trouble, because the compiler helps to validate that values are always within range. Without subtypes, computations can be done with values that are meaningless, which leads to meaningless results. Using subtypes ensures that an exception is raised for an out-of-range value. Unexpected exceptions may be unpleasant, but they are better than incorrect results.

Explain that subtypes of a given base type are all compatible with each other and with the base type. Show some assignments that are always valid (a Positive value to an Integer variable, for example) and some that must be checked at execution time (e.g., an Integer value to a Positive variable).

Section 4.2

Explain the usefulness of developing a program and its documentation simultaneously, declaring variable and constant declarations early and using comments to represent major algorithm steps. Using a NULL statement in the program body (see Programs 4.1 and 4.3) ensures that at each stage the program can be compiled.

Explain that it is helpful to compile the frame of a program, so that declarations and overall syntax can be checked before filling in the details. The point here is that developing a program in a stepwise way does not have to mean that nothing is keyed in or compiled until everything is finished and completely refined. Indeed, the above technique should encourage early compilation. Students without prior experience must learn to feel comfortable at the keyboard and overcome the natural fear of the computer, editor, and compiler. Since they will have to do this sooner or later, it might as well be sooner.

Section 4.3

Students new to programming do not realize the usefulness of building new problem solutions on previous ones. Extension and analogy is very important; students should come to understand that not every problem needs to be solved, nor every program written, "from scratch."

In general, you should make sure that students have machine-readable versions of all the programs, to use as models or frameworks for programs you assign. All the programs are archived on the Internet (available via this website) and also on the CD-ROM supplied with this book.

Just as infants learn to speak by listening to their parents, then imitating, and finally producing creative speech, so students can learn programming by working with well-written examples, first reading and then modifying them. Moreover, we should all follow the principle that once a program has been keyed in to he computer, nobody should have to key it in again. You can save your students much keyboarding effort by assigning initial projects that require modification of program files from the book.

Section 4.4

Enumeration types are easier to teach to novices than to students with experience in other languages. Students with Fortran experience have problems with letting the compiler assign the internal representations; students with Pascal or C experience may be familiar with enumerations but might insist on explicit translation of them into strings for input and output or be unduly interested with the internal values the compiler uses. Try to get them to deal with enumerations as abstractions.

Enumerations are introduced early in this book because they are useful and because an I/O library for them is standard in Ada.

You can motivate Enumeration_IO to students with Pascal or C experience by discussing with them how they would handle I/O in those languages: they'd need a table of valid strings, etc. Explain that in Ada, the I/O package itself is saving them work, by creating and using that table automatically. Instantiating Enumeration_IO is easily seen as the way in which we inform the compiler just which strings (enumeration literals) are to be put in the table.

The case study on color translation is very useful for explaining the position and value attributes, and serves as a small example of how certain translation tables are easily built using enumerations.

Section 4.5

Explain the role of packages (modules, classes) in modern programming, and discuss the four kinds of packages students will use: predefined, compiler-provided, book-provided, and student-written. Design for reuse is one of the most important system design principles to emerge in the 1980's, and packages are the Ada device for building reusable components. It is because of the importance of reuse that we introduce packages early in the book.

Section 4.6

Ada.Calendar is a package whose facilities occur several times in this book. Ada.Calendar is an excellent example of an abstract data type, though the details of this are not discussed until Chapters 8 and 11. In this section, Ada.Calendar is used as a way to introduce function calls and the use of reusable components.

It is easy to use Ada.Calendar to display the date, but do not be tempted yet to extend this to displaying the time of day. The time&emdash;seconds past midnight on the given date&emdash;is returned as a value of type Duration, a fixed-point type with few operators; splitting such a value into hours, minutes, and seconds requires type conversions, which are not introduced until Chapter 8.

In using the Ada.Calendar functions, explain the use of named parameter association. Understanding parameters is easier in Ada than in other languages because of named association,and we use it quite consistently until much later in the book. Ask your students to use the named form; those with experience in other languages may balk at this, but explain that it produces programs that are much more self-documenting, and also allows them to pass parameters without concern for their order.

Section 4.7

Many students enjoy using a screen control package to make the cursor jump around. If your students' terminals are not ANSI or VT100 compatible, the body of this package will not work correctly: Probably, the terminal will display the ANSI command sequences (lots of left-bracket and semicolon characters, interspersed with digits) instead of obeying them. If the "terminal" is a DOS-compatible PC, remember that the ANSI.SYS driver must be installed in CONFIG.SYS. Some installations of Windows do not support the ANSI driver; if you are having this problem, use Jerry van Dijk's substitute body instead.

For other terminal types, you might need a bit of help from your systems people to write a body that will work with your terminals. If you need to do this, you can discuss the fact with the students, explaining that the interface to the package (the specification) did not have to be changed, only the body, and so a program could be made to run without change on several kinds of terminals just by recompiling the package body and re-linking.

This section might be a good place to explain the compilation-order rules for Ada: if a specification is re-compiled, everything that depends upon it ("WITHs" it) must be re-compiled, but if only the body is re-compiled, dependent units need only to be re-linked. Explain the associated benefits of keeping the package specification and body in separate files.