MARCH/APRIL 2006 (Vol. 23, No. 2) p. C3
0740-7459/06/$31.00 © 2006 IEEE
Published by the IEEE Computer Society
Published by the IEEE Computer Society
Software Construction, Part 2
PDFs Require Adobe Acrobat
magic number, magic string: Literal value that's used by a program directly rather than being embedded in a named constant or variable. See also literal (Jan./Feb. 2006).
maintainability: The ease with which a software system can be modified to change or add capabilities, improve performance, or correct defects. See modifiability.
modifiability: The ease with which a system can be changed without introducing defects. See maintainability.
modularity: The extent to which a routine or module is like a black box—the inputs and outputs are well-defined, but the internal workings are kept secret from other routines or modules.
module: A collection of both data and the routines that act on it. Also, a collection of routines that provides a cohesive set of services even when no common data is involved.
module data: Data that can be accessed by any routine within the module in which it's declared but not by routines in other modules. Also known as instance data or sometimes as class data.
named constant: An identifier that refers to a numeric or string value that doesn't change during program execution.
nesting: Embedding one construct inside another—for example, to embed a while loop within another while loop or to embed an if test within a while loop.
object: Any specific entity that exists in a program at runtime in object-oriented programming. An object usually consists of both data and operations on the data. Used informally to refer both to static entities (more properly called classes) and runtime entities.
private: Known only within a single routine or module.
procedure: A routine that doesn't return a value. Compare with function (Jan./Feb. 2006).
programming: The general activity of software development, especially construction activities. See also construction (Jan./Feb. 2006).
pseudocode: English-like statements used for low-level program design.
public: Known to multiple routines or modules.
readability: The ease with which a system's source code can be read and understood, especially at the detailed, statement level.
routine: A function or procedure invocable for a single purpose.
mock object: Temporary dummy objects created to aid testing until the real objects become available.
scaffolding: Computer programs and data files built to exercise software during development but not intended to be included in the final product.
stubs: Scaffolding code written for the purpose of exercising higher-level code before the lower-level routines that will ultimately be used are available.
table-driven method: A scheme that lets a program look up information in a table rather than using logic statements.
test harness: Scaffolding code written for the purpose of exercising lower-level code when the higher-level code that will ultimately exercise it is not yet available.
testability: The degree to which you can unit test and system test a system; the degree to which you can verify that it meets its requirements.
top-down design: A design approach in which a system's functionality is decomposed from high-level concepts into lower-level pieces. Also called top-down decomposition.
understandability: The ease with which a system can be comprehended at both the system-organizational and detailed-statement levels. Understandability has to do with the system's coherence at a more general level than readability does.
unit: A logically separable part of a computer program. A unit could be a routine, module, or larger subprogram.
unit test: Testing of individual routines and modules by the developer or an independent tester.
unit test framework: An environment that facilitates unit testing, such as JUnit.
variable: A data item whose value can change during program execution.
Steve McConnell is CEO and chief software engineer of Construx Software. Contact him at firstname.lastname@example.org.