Chapter 4 review. Are the following statements true or false? Explain why or why not.

a) Much of the complexity of programming-in-the-large is communication.
True.  In two senses: software components communicating with each other and human analysts, programmers and users communicating with each other.

b) A virtue of hardware components is that it’s relatively easy to get them to do new tricks.
False. That's the virtue of software: it's relatively easy to change. It's also the greatest challenge to management.

c) Modules, such as Java classes, can help manage change and maintain order in software.
True. Modules prevent outsiders from changing implementation of modules.

d) Comments, such as those that determine the meaning of variables and functions, can help reduce the cost of software maintenance.
True. Programmers find it much easier to understand well-commented code, making it easier to debug or improve it.  Of course, comments are helpful if they are true (invariant) and clear (well written).

e) A “waterfall” model of the software life cycle encourages frequent re-analysis or re-design.
False. Implicit in this model is gravity, urging flow downward, stage by stage. Returning to earlier stages should require effort (like salmon swimming upstream), i.e., management approval.

f) A use case describes a problem solution or algorithm from a system's point of view.
False. A use case describes a problem scenario from a user's point of view.

g) A use case describes one scenario.
False. A use case may describe more than one scenario, typically a main scenario and alternatives branching off the main scenario at various points.

h) A requirements specification explains how to implement a program.
False. Requirements analysis emphasizes what the system should do, not how. An analyst's main job is to understand the problem and its domain.

i) Definition of key terms is an important activity of the analysis stage.
True. Defining terms is an excellent way to understand the problem and its domain. These terms often become objects in a program solving the problem.

j) Design shifts from analysis (“what”) to implementing a program in Java (“how”).
False. Design does shift to "how" issues, but not in any particular programming language. The output of design is a language-independent description of data (types and variables) and algorithm (in pseudocode) to solve the problem.

k) It's a good idea to have strong coupling and dependencies between modules or classes.
False. It's better to have loose coupling so that changes in one module is less likely to require changes in other classes in a system. Loose coupling can hold down the cost of software development and maintenance.

l) In UML, composition and inheritance relationships are always 1 to many (1..n).
False. Inheritance relationships are usually 1 to 1, though some languages permit multiple inheritance.

m) Pseudocode is fake Java code—pretty useless!
False. Pseudocode-describing an algorithm without worrying about language-specific details-is very useful. Coding can then start with pseudocode (as comments), implementing code that should correspond to the pseudocode.

n)Linker errors occur when a header file is missing or in the wrong directory.
False. Remember, header files contain source code; the linker combines object code. Linker errors may occur when object code, such as library files, are missing or in the wrong directory.

o) If a program runs without crashing unexpectedly, then it’s correct and you can hand it in—hooray!
False. There may still be logic errors in the program. You need to make sure the program is producing the right output, as predicted by the requirements. It's a good idea to develop test data and to make sure the program produces predicted results for the test data. When you hand in a program, hand in sample results with test data, for boundary as well as core cases.

p) When a compiler attempts error recovery, it may skip over some source code in a program.
True. For example, it may skip to the next semi-colon (;) in order to try parsing from the next statement. Thus you may find that several error messages pertain to one problem in your source code, so you ignore some of them; yet it may still be useful to look at error messages pertaining to lines further down in a program.

q) It’s a good idea to test with boundary values, not just core values.
True. Boundary values test for cases that are more likely to cause problems. If you don't test for difficult cases, there's a good chance that bugs will surface later!

r) Debugging is another problem solving activity, only more fun.
True. Well, whether or not it's fun is a matter of opinion, but it is a problem-solving activity. Use decomposition by breaking the problem down into pieces (for example, by inserting output statements to trace parts of the program until you narrow in on the line that causes the problem). Use analogical reasoning by recalling similar problems and adapting their solutions-you'll get better at this with experience!

s) A breakpoint is where a program crashes, even more fun.
False. A breakpoint is where a program stops execution, at a point predetermined by the programmer, so that the programmer can examine the state of the program, such as the value of relevant variables, at this point. Must debuggers provide a breakpoint facility.

t) A structured walkthrough can help discover flaws in the design before implementation.
True. Just explaining to someone else what you propose to do may help a designer discover mistaken assumptions or faulty solutions. Structured walkthroughs are useful at every stage; for example, during debugging, explaining what you think the code is doing may help you to realize that the code isn't doing what you think it should. Aha!

u) Newer models of the software development life cycle allows for re-analysis and re-design.
True. Newer models allow for incremental and iterative development. It's not that old results are thrown out though; rather, each iteration builds and improves on earlier ones.

v) In the context of software engineering, XP refers to a release of a popular operating system.
False. It refers to eXtreme Programming, which puts more emphasis on iterative and incremental development, keeping the customer involved throughout the process, and pair programming.

w) Pair programming reduces productivity because two people are working at the same thing.
False. Pair programming has been shown to increase productivity, but not just because two people are working on the same thing. It wouldn't work if the two people worked in separate places. Rather, they must work together, with one person entering code and the other critiquing it, pointting out deficiencies in logic or style.

x) Pair programming promotes cross learning.
True. The two programmers learn often from each other. It has been shown to help beginners learn programming.

y) Planning tests before writing code is a good idea.
True. The designers of a software unit or class should specify the tests required to assure that the implementation works correctly.

More questions:

Managing a large software system is like trying to hold 400 ping-pong balls in your arms.
True. The complexity can increase exponentially with the number of elements subject to change, particularly if we need to consider all the possible interactions between them.

Some of the work of analysis and design can and should appear in a program’s code.
True. Putting the purpose, scope, definition of terms and pseudocode into the program as comments is a very good starting point. Just make sure the code does what the comments says it should!