Posts Tagged ‘Formal Testing at all levels’

Development of Utility Libraries

October 26, 2012

The activity associated with development of utility software parts libraries will be presented here.

In order to use the certification software parts library in the development of the class base software development process, it is necessary to include a script call capability in this library.  This effort will be reported in this sub-section of the utility blog.

CERTIFICATION SATURDAY ACTIVITY: The two software parts needed to add the script calling capability to the certification software parts library have been prepared. The next task will be to checkout / formal-test this additional capability.

CERTIFICATION TUESDAY ACTIVITY: The checkout / formal-test process has been started and the basic calling process has been successfully checked. The calling process that enables the client to become a subsequent service function.

Advertisements

Can Programming Be Strictly Portable Relative To Language?

October 19, 2012

The activity associated with development of strictly portable methods of software development will be presented here. Included in this Portability effort will be Windows based C, C++, C#, and Visual Basic; and Linux based C and C++.

FRIDAY:  The certification / common name issues of the includes software parts library will be reexamined and the development process re-planned.

MONDAY: A re-examination of the common class base software parts revealed the basic challenge. The act of referring to a class another class (sub-class) involves a number of sets of commands; i.e., the sub-class includes, sub-class typedefs, and sub-class data structure. The basic problem is that all of the include instructions must be executed first, then all of the typedef instructions next, and so forth. A script call instruction can satisfy this requirement. The next task will be to implement and test an appropriate certification command. This effort will be reported in the utility blog.

Development of Utility Libraries

October 19, 2012

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.

My apologies for inadequacies in my blogging efforts.  I have had a non-related significant distraction from my research/development activities. These distractions have not as yet been completed.  Hopefully in a few weeks…

SCRIPT FRIDAY ACTIVITY: Being able to pass parameters to the script in the _RUN_SCRIPT command is next script library upgrade to be performed. In as much as I do not want to lose the use of this library for any length of time, this upgrade process will performed slowly with tiny steps.

Development of Utility Libraries

October 12, 2012

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.

My apologies for inadequacies in my blogging efforts.  I have had a non-related significant distraction from my research/development activities. These distractions have not as yet been completed.  Hopefully in a few weeks…

SCRIPT TUESDAY ACTIVITY: The transfer of text data from a calling script to the called script via the calling arguments has been successfully accomplished. There is still integration problems associated with the use of this data in the called program. The solution of these integration problems will be addressed next.

SCRIPT THURSDAY ACTIVITY: The software parts associated with a script calling another script have been modified and checked out. These software parts can now be used. Being able to pass parameters to the script in the _RUN_SCRIPT command has not been implemented.  There is still work to be done to upgrade the script library.

Development of Utility Libraries

September 28, 2012

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 THURSDAY ACTIVITY: The modifications of the calling load commands have been made and partially tested. The testing of this command can only be completed when these calling commands are executed. The inclusion of this error detection software part will continue.

Development of Utility Libraries

September 21, 2012

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 TUESDAY ACTIVITY: I have prepared an error software part that
detects a lack of initial preparation before loading the commands. The
implementation of this software part is progressing. The modifications
of the calling commands will be performed next. This will include the
inclusion of this error detection software part.

Can Programming Be Strictly Portable Relative To Language?

August 31, 2012

The activity associated with development of strictly portable methods of software development will be presented here. Included in this Portability effort will be Windows based C, C++, C#, and Visual Basic; and Linux based C and C++.

FRIDAY: Currently, I believe that the common name problem can be resolved using the script calling capability of the script software parts library. This require a different form of certification chain capabilities which will probably require upgrading the certified copy library. This will be examined after I upgrade the associated software parts of the script software parts library.

Development of Utility Libraries

August 31, 2012

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.

Development of Utility Libraries

August 24, 2012

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 THURSDAY ACTIVITY: It has been decided to improve the handling of parameters in the script calling software parts.  This will include optional parameters in the base software part that executes the script.

Economical Rigorous Software Testing at All Levels

August 10, 2012

The ability to thoroughly and economically test software work-products at all levels is a necessary requirement of the error-free software development process.  The Programmable Software Development Environment has a Monte-Carlo (random generator) based test system which is capable of satisfying this requirement.

Historically, this tool has been very difficult to set up and hence has only been experimentally use. Recently, a library of software parts has been developed which greatly simplifies its use. As a consequence, it is being successfully used in the checkout and formal testing required in my portable software development research and development activity.

This blog will be used to focus upon on my test related research and development efforts.

FRIDAY: A local script only exists in the task in which it was created. It is discarded when this task is complete. A global script that calls a local script in a particular task will fail to execute in a subsequent task.  The associated error is now properly reported. The single line this script calling capability for global and local scripts has now been sufficiently tested that it can been used for manual development.

SATURDAY: To determine what additional changes are needed to the script software parts library, I need to answer the question: How much is the script going to simulate a macro?  In the past, I made a limited effort. Maybe a complete simulation is needed. I will re-examine this question

MONDAY: To make the script simulate a macro, I will need to improve the script calling arguments and return capabilities, and both the automatic and global data storage. I have tentatively decided to proceed with the update.  The script calling arguments will be first. The planned improvement will include a parameter capability for the _RUN_SCRIPT macro.