Information Technology Reference
In-Depth Information
1.
Because each object is associated with a particular component of the system, object-
oriented designs can be easier to understand.
More easily understood designs can save time during the programming, testing, and
maintenance phases of a software project.
2.
Because each object hides its state and private data from other objects, other objects
cannot accidentally modify its data items.
The result can be fewer errors like the race conditions described in Section 8.5.3.
3.
Because objects are independent of each other, it is much easier to reuse components of
an object-oriented system.
A single object definition created for one software system can be copied and inserted
into a new software system without bringing along other unnecessary objects.
When the design has reached a great enough level of detail, software engineers
write the actual computer programs implementing the software system. Many different
programming languages exist; each language has its strengths and weaknesses. Program-
mers usually implement object-oriented systems using an object-oriented programming
language, such as C++, Java, or C#.
The purpose of validation (also called testing) is to ensure the software satisfies the spec-
ification and meets the needs of the user. In some companies, testing is an assignment
given to newly hired software engineers, who soon move on to design work after prov-
ing their worth. However, good testing requires a great deal of technical skill, and some
organizations promote testing as a career path.
Testing software is much harder than testing other engineered artifacts, such as
bridges. We know how to construct scale models that we can use to validate our de-
signs. To determine how much weight a model bridge can carry, we can test its response
to various loads. The stresses and strains on the members and the deflection of the span
change gradually as we add weight, allowing us to experiment with a manageable num-
ber of different loading scenarios. Engineers can extrapolate from the data they collect
to generate predictions regarding the capabilities of a full-scale bridge. By increasing the
size of various components, they can add a substantial margin of error to ensure the
completed bridge will not fail.
A computer program is not at all like a bridge. Testing a program with a small
problem can reveal the existence of bugs, but it cannot prove that the program will work
when it is fed a much larger problem. The response of a computer program to nearly
identical datasets may not be continuous. Instead, programs that appear to be working
just fine may fail when only a single parameter is changed by a small amount. Yet
programmers cannot exhaustively test programs. Even small programs have a virtually
infinite number of different inputs. Since exhaustive testing is impossible, programs can
never be completely tested. Software testers strive to put together suites of test cases that
exercise all the capabilities of the component or system being validated.
