3.2.3 Standard modules (library routines) used in software solutions
Students Learn About:
reasons for the development and use of standard modules
requirements for generating a module or subroutine for re-use, including:
–identification of appropriate modules or subroutine
–appropriate testing using drivers
–thorough documentation of the routine:
-author
-date
-purpose
-order and nature of parameters to be passed
issues associated with reusable modules or subroutines, including:
–identifying appropriate modules or subroutines
–considering local and global variables
–appropriately using parameters (arguments
Students Learn To:
•develop and appropriately document a module for use by others
•correctly incorporate a standard module into a more complex solution, passing parameters effectively
Modules and functions
A function or module is a separate block of instructions that performs a well-defined task. A well-written function has clear input and output specifications.
Functions are the building blocks of algorithms and functional decomposition is the heart of structured programming. Of all the issues within algorithm design, decomposition is the most important.
So you must be clear on how functions work and why they ought to be used.
This section deals with these issues. It is modestly technical in nature.
Concentration and practice are required if you want to become fully aware of the details.
General issues Decomposition and reusability
You already know that functions are used to break an algorithm into separate parts so that the work done by the algorithm is distributed into smaller chunks.
The other benefit is that once they are developed and tested, and if written the correct way and with a clear purpose, functions can be ‘plugged into’ any algorithm that requires their tasks.
Reusability is important to software developers who want to be able to create robust products with a minimum of coding and in a minimum of time.
Function libraries
In the software development industry, large collections of well-tested and reusable functions are stored in ‘function libraries’. Suitable function libraries can be included, or ‘imported’, into any new project.
This means that the project can be built by designing the overall structure and then activating functions in the library to do much of the processing.
Most programming languages are supported by ‘standard function libraries’.
These are fully refined and tested collections of functions that have been standardised by either the vendor of the language or an international body of experts.
The call and return mechanism
In all programming languages and algorithm designs, functions are activated by ‘calling’ them; the algorithm that activates a function is known as the ‘calling code’ or sometimes the ‘client code’.
When a function is called from somewhere in an algorithm, the current processing of that algorithm is postponed.
The called function then starts working and takes control of all processing.
When the function has performed its task and eventually terminates, control reverts to the algorithm that called it, which then continues on with any of its remaining instructions.
So, in general terms, the principle of call and return is that, whenever a function terminates, control is always returned to the place from which it was called.
String concepts
In traditional systems strings were not defined directly in a programming language. Instead, a programmer had to work with the individual characters that made up a message or word.
To do this efficiently, the programmer used techniques which were very similar to those seen in the previous two sections.
That is, a string was represented as an array of characters.
It is a tedious job for programmers to write all their own character array processing routines from scratch.
Some standardised functions are required, and once these are written and well tested they can be stored in a function library and used over and over again in future applications.
Linking, including use of DLLs
Subprograms used by a main program can come from a number of sources.
One of the sources is the programmer who creates a subprogram to perform a task that is specific to the program.
A second source of subprograms is the library that comes with the development system, for example the subprogram that calculates the square root of a number.
A third source is the set of subprograms that form part of the operating system, for example a subprogram that copies a file from main memory to an external storage device such as a hard disk.
When a program requires a particular subprogram, its address is incorporated into the program by a part of the translation system called a linker.
The linker places a call to the subroutine into the program.
When the program reaches that point in its execution, the subprogram is run and control is then passed back to the program at the end of the subprogram.
A special type of subprogram library, known as a DLL (Dynamic Link Library) is in common use these days.
A DLL is used in the same way as any other library, however, the library can be updated with a new one, all programs that use the DLL automatically linking to the new version.
This allows for modifications to be made to the library after a program has been written, the changed subprograms are, however, automatically incorporated into the program when it is run.
