Blogs >> Technology >>
Development of Utility Libraries
The activity associated with development of utility software parts libraries will be presented here.
The effort associated with the development, upgrading and testing the script software parts library will be documented here. Specifically, the script software parts library will be upgraded to behave more like a software part. It will also be formally tested.
SCRIPT FRIDAY ACTIVITY: The handling of the optional parameters for the script calling software parts will be examined first. Corrections and improvements will be made as needed.
SCRIPT SATURDAY ACTIVITY: Currently, The software part that loads the script calling argument specifies both the calling argument as well as the called parameter which has to be defined in advance. This is not a normal coding method. Calling a subroutine does not require knowledge of called subroutine parameter names. This can be solved by expanding the instruction for beginning loading a script to include a list of parameters. The single command that currently begins loading a script would optionally be replaced by three commands: one that initializes the loading process and begins the parameter list, one that adds a parameter, and one that ends the parameter list.
SCRIPT SUNDAY ACTIVITY: Originally, a data storage capability was provided for each script. This capability provided both the calling parameters for the script as well as other data storage requirements and is retained only during the execution of the script. The primary difference between the parameters and other data storage elements is the loading restrictions: Parameters can only be loaded from the calling script and the other data storage elements can only be loaded from within the called script. To implement this restriction, we must develop both capabilities at the same time.
SCRIPT MONDAY ACTIVITY: The software parts needed to define a parameter and a data storage element have been prepared. The next task is to define the necessary software parts to organize this capability at the beginning of the script before the first executable script command. Any parameters should come first, then any data storage elements, and then any executable commands. The necessary software parts to implement and enforce this order will be prepared next.
SCRIPT TUESDAY ACTIVITY: The most efficient solution to organizing the parameter and data storage element definition at the beginning of the script before the first executable script command was to build a "software fence"; i.e, a software part that must be inserted after the last data definition statement and before the first executable commands. This software part has been prepared and tested. The next step is to modify the script calling and data loading software parts.
The effort associated with the development, upgrading and testing the script software parts library will be documented here. Specifically, the script software parts library will be upgraded to behave more like a software part. It will also be formally tested.
SCRIPT FRIDAY ACTIVITY: The handling of the optional parameters for the script calling software parts will be examined first. Corrections and improvements will be made as needed.
SCRIPT SATURDAY ACTIVITY: Currently, The software part that loads the script calling argument specifies both the calling argument as well as the called parameter which has to be defined in advance. This is not a normal coding method. Calling a subroutine does not require knowledge of called subroutine parameter names. This can be solved by expanding the instruction for beginning loading a script to include a list of parameters. The single command that currently begins loading a script would optionally be replaced by three commands: one that initializes the loading process and begins the parameter list, one that adds a parameter, and one that ends the parameter list.
SCRIPT SUNDAY ACTIVITY: Originally, a data storage capability was provided for each script. This capability provided both the calling parameters for the script as well as other data storage requirements and is retained only during the execution of the script. The primary difference between the parameters and other data storage elements is the loading restrictions: Parameters can only be loaded from the calling script and the other data storage elements can only be loaded from within the called script. To implement this restriction, we must develop both capabilities at the same time.
SCRIPT MONDAY ACTIVITY: The software parts needed to define a parameter and a data storage element have been prepared. The next task is to define the necessary software parts to organize this capability at the beginning of the script before the first executable script command. Any parameters should come first, then any data storage elements, and then any executable commands. The necessary software parts to implement and enforce this order will be prepared next.
SCRIPT TUESDAY ACTIVITY: The most efficient solution to organizing the parameter and data storage element definition at the beginning of the script before the first executable script command was to build a "software fence"; i.e, a software part that must be inserted after the last data definition statement and before the first executable commands. This software part has been prepared and tested. The next step is to modify the script calling and data loading software parts.
|
|
