12.3 What Is Program Management?

< Day Day Up >

When the functional and object relationships needed to solve a problem have been designed, as well as the objects that will be used, many programmers believe that the design process is complete, and they begin to implement the system. However, an important part of the implementation has not yet been considered. When a program representing a virtual entity (a design) is actually created, the objects that have been designed must be implemented and a physical artifact (a program) produced. This process of creating the physical artifact carries with it a host of implementation concerns not present in the design — for example, naming conventions; object, method, and variable scope; organization of the files necessary to create the program; or source code management and control. These are not part of the design of the system, which is what the system does and how it does it. Instead, these are issues of how to manage the product that is being created. These concerns create the physical infrastructure that allows the program to be implemented in a way that allows it to be easily manipulated and controlled by the programmer. They also create limitations on the design that must be addressed before implementing the program.

Booch [BOO91, p. 51] states that, "Modules serve as the physical containers in which we declare the classes and objects of our logical design." Creating and managing the modules is what we wish to do and what obviously must be done for all programs and systems. An important question is, "How does the creation of these modules affect implementation of the design?"

When considering how implementation of the physical program into modules affects the design, a question is raised regarding to what degree the implementation details for the modules are formalized and enforced. The best design can still result in a mess that is not properly modularized and controlled, but excess control can limit the ability of the programmer to make decisions and can affect the design badly. The question we want to answer, then, is, "What degree of formalization and control should be placed on a program?"

To better understand this, the process of managing a program can be thought of as a two-dimensional matrix. One dimension is the degree of formalization, which can be none, informal, or formal. The second dimension is the way in which formalization is controlled, which can be none or by management fiat, external system validation, or internal system validation. This matrix can be applied to each implementation attribute (such as naming or source code control), and choices can be made regarding how to manage that attribute. For example, consider naming conventions in a program. The naming of variables could be left completely up to the programmer (no formalization), it could be done according to "best practices" but with no precise definition of the best practices (informal), or the naming convention could be explicitly defined for every variable (formal). In order to ensure that these practices are followed, the programmer could simply be told to follow a standard (no control), the manager could ask for periodic code samples to review (management fiat), a code walk-through could be done on every module to identify incorrect variable names (external system validation), or, finally, a precompiler could be written that automatically checks each variable name to ensure that it follows standards (internal system validation). Exhibit 1 shows these options. In Exhibit 1, the combinations of options that are not marked with an X are not possible; for example, without a formal definition of naming standards it is possible to identify bad names in a code walk-through, but it is impossible to automate the procedure for finding bad names.

Exhibit 1: Standards

	Degree of Formalization
Formalization Technique	No Formalization (Programmers Choose Names for Variables)	Informal (Programmers Agree to Use "Best Practices")	Formal (Formal Programmers Document Details Naming Standards)
None: no control
Management fiat: Manager checks code and bases part of evaluation on standards followed.	X
External program validation: Code walk-through, rules in an IDE	X
Internal system validation: Precompiler check of variable names that must be passed to compile code.	X	X

Which of the options in this chart is the best? It depends on how tightly the particular implementation attribute is to be controlled. This is not something that will be the same for all attributes, or for any one attribute for every program that is implemented. What is clear is that the more important the control of an implementation detail is to the success of the program, the more formally it should be defined and the more rigorous the control placed on it. In fact, some of these attributes were considered so important that when the Java language was defined control of these attributes was placed in the language itself; for example, all Java source codes must exist in a file with a ".java" extension.

The rest of this chapter is divided into two sections. Section 12.4 covers implementation attributes not defined in the Java language, and Section 12.5 discusses implementation attributes that are defined in Java. In Section 12.5, the implementation attributes are compared to C++, where the definition and control of these attributes tend to be less formal and less rigorously enforced, with the intent to show why the particular attribute was formalized and included in the Java language.

< Day Day Up >