TRIZ for Perl-Programming

	Bookmark This Page Email This Page Format for Printing

First presented at TRIZCON2001, The Altshuller Institute, March, 2001.

Michael Schlueter
Philips Semiconductors
Stresemannallee 101, D-22529 Hamburg GERMANY
Phone: +49 40 5613 3423; Fax: +49 40 5613 3392
Email: Michael.Schlueter@philips.com

When implementing a program a potential risk is revealed from discussions. The chance is taken to apply TRIZ to a software problem. The specific mechanism and the required resources to create the identified disaster by the prototype are worked out. TRIZ’ standard solutions are utilized to derive strong alternative implementations, which will eliminate the disaster completely. As a by-product a preliminary list of Perl-fields is derived in analogy to the lists of physical and chemical TRIZ-fields.

Members from the development department can pass problems to a support crew and ask for a solution. In the past this process was organized by a human-based help-desk facility. In an attempt to replace a human as the source of energy and control a program is developed, called CRC2000, which allows to submit a problem statement to the support crew via the available computer network. CRC2000 provides required functionality, which is not available from the current email system.

From a users perspective the description of the problem, the severity and the allowable time-period has to be entered into a dialog-form. When clicking with the mouse on the “OK” button (Figure 1) the required processes are started. A user could click on “Cancel” by intention to abort the program. From discussion it became evident that there is a severe risk:

• A user could enter all required information
• Instead of clicking “OK” one could click on the “Cancel” button unintentionally
• From a user’s perspective the information seems to be passed to the support crew
• In reality all information is lost

The program is implemented in Perl (language; cf. appendix) and Perl/Tk (graphical user interface). The author is fluently in Perl, whereas Perl/Tk is relatively new to him. It is required to prevent the “Cancel”-disaster and to identify suitable ways of implementation in Perl and Perl/Tk.

There are two basic tasks involved in this problem:

1. Understand the mechanisms.
2. Reveal involved and required resources within the system.

The author decided to use Zinovy Royzen’s TOP-approach, which is a resource-based way to model functions [1]. Compared to SuF-models Royzen includes also the result of an action explicitly, which he calls “product” or “modified object”. A comparison of these two models can be found in [6].

At first glance clicking the “Cancel”-button may appear to be a conflict. However, the intended and the unintended use of this button are completely separated in time (Figure 2).

Figure 2 Analyzing the "Cancel"-event in time

Figure 3 Simplified Perl/Tk code, showing the problem

There is no way to hit this button with intention AND without intention during the same period of time. When the button is clicked, a special button-event signal is created and passed to the messaging system from Perl/Tk. Control is immediately passed to other parts of the program. In the CRC2000-program the exit() subroutine is associated with the “Cancel”-event. Even, if subsequent “Cancel”-events should be stored in the message-queue they will be lost, because the program terminates. The only way to create a new “Cancel”-event is to restart the program and to click the Cancel button again. Figure 3 shows the important part within the Perl/Tk code, which is explained in more detail in the appendix.

For further analysis one can regard the unintended “Cancel”-event as a harmful function:

Model: Cancel //> Information => Information_lost

Read: “Cancel acts harmfully on the Information. As a harmful result, information is lost.”

To reveal the relevant mechanisms of losing information, which are possible within the CRC2000-program, the opposite problem is solved next. This effective approach has been proposed to predict problems many times before [e.g.: 1, 2, 3]. For the moment it is required to invert the problem and to regard the harmful cancel-action as a desired useful action:

Model: Cancel à Information => Information_lost

Read: “Cancel acts usefully on Information. As a useful result, Information is lost.”

“Find ways to loose information by the Cancel-event. Utilize only available resources and fields. Guarantee loss. Make it an inevitable loss-field.”

As a boundary condition the programmer must have ensured that a “Cancel”-button is available, visible to and usable by a user. The task is to reveal problems created by a working program.

The only available resource, which can establish disaster on a user activity, is the “Cancel”-button itself. From all options of the Button-widget only the command-option has the ability to create the desired disaster:

-command => callback

When a Button is created in the Perl-program the command-option is one of its parameters. callback specifies a subroutine which has to be executed when this Button is used.

1) A Button can be created without using this option:

$mw->Button(

-text=>”Cancel”

)->pack;

2) As a standard programmers assign the exit routine to a “Cancel”-button:

$mw->Button(

-text=>”Cancel”,

-command=>sub {exit};

)->pack;

3) Programmers can perform other actions before actually calling the exit-routine:

$mw->Button(

-text=>”Cancel” ”,

-command=>sub {some_other_function_first(); exit};

)->pack;

sub some_other_function_first {

# some code to execute

}

4) Programmers can call any other function instead:

$mw->Button(

-text=>”Cancel” ”,

-command=>sub {some_other_function_first();}

)->pack;

sub some_other_function_first {

# some code to execute

exit();

}

If the exit-routine is omitted, the program can not terminate. To satisfy the boundary conditions of a working program, only variants, which use the exit-routine, need to be considered (i.e. variant 2-4). As a result, the disaster must be created by the callback routine(s) before calling the exit-routine.

The information stored in the internal data structures of the Tk-widgets is lost, when:

• Information is not stored permanently
• Information is overwritten

The second possibility is not implemented in the prototype. There are no plans to do it, so this option is not considered.

Task 1: Find ways to store the information temporarily (not long enough).

Requirement1: Store information, but not long enough.

Figure 4 Operating zones of desired disaster

Figure 4 indicates the operating zones, where the desired disaster must be guaranteed.

There is one trivial solution:

• Do not store any information on the disk.

Storing information in a file on a harddisk is the only way to store information permanently on a computer, once a program is terminated or the whole system is turned off. This solution is already implemented in the prototype (no storing mechanism is available for this event) and we want to look for more ways to accomplish Task 1.

The information has to be lost:

• Within the variable
• Within the callback routine
• On the network
• On the disk

The relevant zones of desired disaster are indicated in the figure.

As discussed above the information must be lost between invoking the callback function and before calling the exit-routine. Figure 5 shows the required operating times of the desired disaster.

Figure 5 Operating time of desired disaster

Capability of the mentioned Resources:

1. lose information within the variable of the widget:
   The information is lost within the widget-variable when the widget is destroyed. This happens far later than the call to the exit routine. So this resource does not have the required property in time.
2. lose information within the callback routine:
   The timely requirement is fulfilled. This resource can be utilized.
3. lose information on the network:
   There is no way to lose information in a controlled way on the network. Network errors are beyond the scope of this investigation. So this resource can not be used to create the desired disaster.
4. lose information on the disk:
   When the information is not stored on disk, there is no way to retrieve it after the CRC2000-program has been terminated. This resource can be utilized.

As a summary, the disaster can be created by the trivial event:

• Do not store any information from any widget on disk when performing the Cancel-callback function and before calling the exit() routine.

This way the loss of information is guaranteed when the user hits the Cancel button unintended.

In this case there is only one trivial mechanism available to lose information when hitting the Cancel-button under the boundary conditions mentioned. The next step is to identify ways and available Perl-resources to prevent this disaster. We now return to the original model of the harmful action, which has to be solved within the operating zones and operating times indicated by Figures 4 and 5:

Model: Cancel //> Information => Information_lost

Information is lost between starting the callback routine and before staring the exit-routine by not saving any information from any widget to disk.

 

According to Royzen there are 6 proposals, how to eliminate harmful action directly [1]:

1. Use an insulator between „Cancel“ and „Information“
2. Apply a compensating field (algorithm etc.)
3. Protect the Information from the Cancel button
4. Modify „cancel“ in such a way, that the harmful action disappears
5. Modify the „Information“ in such a way, that it becomes insensitive against „Cancel“
6. Alter zone (point of action) or duration or both of „Cancel“ to reduce or eliminate the harmful action.

Insert a (yet unknown) insulator Sx, which will insulate „Information“ from „Cancel“ and yields „Information_available“.

1. Requirements for Sx:
   „Cancel“ must stop the program. „Cancel“ must not loose information entered so far.
2. WHERE should Sx insulate „Information“?
   The Perl-variable, that keeps the information, must be insulated from cleaning up the variable.
3. WHEN must Sx insulate „Information“ ?

No info entered | info entered | Cancel | exit()
----------------------------------------X-----------> time

Sx must insulate „Information“ after „Cancel“ has been pressed and before program exits.

According to Royzen there are 10 possible ways (A-J) to introduce an insulating property.

Proposal A:

Insulate „Information“ by using a substance that is used for this purpose.

END{} - block from Perl could be used. Perhaps also the BEGIN{} block when information is eventually restored. Information could be stored on disk via the END-block and re-read via the BEGIN-block, on resume.

The END{} - black is executed as late as possible by Perl. From a test program it has been verified, that the widgets still exist when the END-block is executed. So the information contained in the widgets could be retrieved and stored to disk for later use.

Proposal B:

Insulate „Information“ by inserting another additional „Information“, which is exactly the same „Information“

• use an extra directory for the information, treat it and mark it as „preliminary“ ; save information continuously on-disc. (in the current concept „Information“ would have been stored finally on disk. The suggestion is to use a copy of the original object „Information“)

Proposal C:

Insulate „Information“ by using another „Cancel“ - object, which is exactly the same.

• In Perl/Tk there is a callback function associated with a Cancel-Button. Deviating from this proposal, this suggestion guides the author to consider the callback function of the original „Cancel“-Button, like setting the buttons options to -command=>&restore (look for details in Perl/Tk; there will be a restore() function defined somewhere else to perform the insulation function.)

And so on until proposal J [1]. Then there are more proposals on using modified resources. There are a similar amount of proposals for the other 5 direct elimination methods, mentioned above.

During this analysis it is necessary to create sufficient SuF-models many times. A common procedure is to go through lists of TRIZ-fields and to check, whether or not a specific field might provide the required action. The author had access to lists of mechanical-, chemical-, electric-, magnetic-, thermal- and nuclear-fields.

Using these lists was very inspiring for solving software problems. However, software engineering has become a mature business, with very powerful creation processes, providing new TRIZ-fields and new TRIZ-resources. These should be revealed to better utilize state-of-the-art knowledge from software industries.

A preliminary compilation of Perl-fields is given in the appendix, which should allow to use Perl more effectively. For example during analysis it becomes necessary to introduce an access-field into a program. How could this be done in Perl?

One could use specific substances, like S_File, S_List, or S_Hash (cf. appendix). One could introduce S_use or S_require, which are Perl-specific functions to include other program code. The programmer now can choose the most suitable solution. In this particular case proposals 1) and 2) or 1) and 3) will be combined in practice, when persistent storage of data is required. Proposals 2) or 3) may be used individually when data only need to be accessed during run time of the program.

Initial (insufficient UA):

Proposals (sufficient UA):

Code-Examples:

Experienced programmers will analyze the situation in almost the same way as it is shown in this case study. To the authors personal experience there can be an important difference. From practice the author knows about certain traps and certain problematic situations. With this kind of background many problems can be identified either analytically by following the logic of the program, by gut feeling or by sixth sense. Unfortunately many times problems are only identified by complaints.

When implementing specific solutions there may be some uncertainty or even unawareness left to the programmer. Applying TRIZ analysis, and especially the sabotage-technique, creates a systematic, firm understanding of the situation. For example in this case study trivial and more interesting loss-fields could be identified. From enforcing precision of thinking hardly any uncertainty is left. All potential problems and all relevant resources can be revealed.

While a gifted programmer may achieve the same amount of precision in analysis, the author was struck by the enormous amount of strong alternatives derived by TRIZ’ standard solutions. Most of them could have been implemented and many where unexpected and surprising.

TRIZ is applied successfully to a problem from software implementation. TRIZ helps to reveal systematically a specific disaster mechanism when using the discussed software. Once revealed, many strong countermeasures are identified, which can be implemented in Perl and will eliminate the specified disaster completely.

Surprisingly, the discussed problem turns out to be a quite trivial one from a programmer’s point of view. However, the disciplined TRIZ-analysis provides the necessary input to propose a variety of countermeasures.

Perl offers an overwhelming amount of possibilities and alternatives to accomplish a task. The TRIZ-process helps to exactly identify the required Perl-resources to eliminate the discussed problem. TRIZ makes the author a more effective programmer, saving valuable development time.

As a by-product a preliminary list of Perl-fields is derived, which can be used to identify harmful and useful resources or to derive concrete solutions for implementation. This work should be continued and extended to other programming languages.

Generic TRIZ-tools should be applied during the specification and concept phase of software development. This would allow coming up with more innovative and more capable software concepts right from the start.

The different resources, effects and fields, found in software systems, should be incorporated into the TRIZ knowledge base. This would allow improving software implementations by TRIZ.

Michael Schlueter graduated in low-energy solid-state physics in 1987 at the Christian-Albrechts-Universitaet, Kiel. He visited CERN in 1984 as a summer student and other high energy physics facilities to witness front-end research. He started at Philips Semiconductors, Hamburg in 1986 and held various support-related positions for IC-development. Very early he started evaluating methods for quality improvement. He began with TRIZ in 1996, after following a presentation of Zinovy Royzen at the Taguchi Symposium in Los Angeles. He tried many contemporary approaches to TRIZ and is an active promoter of TRIZ within Philips.

1. TRIZ Workshop, Zinovy Royzen, Philips Semiconductors Hamburg, 1999
2. “Sabotage-Technique”, Alla Zusman, private communication Oct. 2000
3. “Anticipatory Failure Determination”, Dana Clarke, private communication Dec. 2000
4. “Programming Perl”, Larry Wall, Tom Christiansen & Randal L. Schwartz, O’Reilly, 2nd Ed. Sept. 1996.
5. Comprehensive Perl Archive Network, CPAN, http://search.cpan.org
6. “Tool, Object, Product (TOP) Function Analysis”, Zinovy Royzen,
   http://www.triz-journal.com/archives/1999/09/d/index.htm
7. “Learning Perl”, Randal L. Schwartz&Tom Christiansen, O’Reilly

Perl stands for a “Practical Extraction and Report Language”. It was developed by Larry Wall to simplify routine tasks of computer management. Perl has matured to a robust, powerful scripting language, which combines the advantages of many well proven programming languages, like C, C++ or FORTRAN, and Unix tools, like awk or sed.

Perl/Tk is a special package, which ports Tcl/Tk to Perl. Tcl is a scripting language while Tk is a toolkit. Both together allow Unix programmers to create graphical user interfaces (GUI’s) for the X window server. Perl/Tk provides a subset of Tcl/Tk to Perl programmers.

Widgets are discrete objects of small size. In Perl/Tk they denote elementary graphical units, like a Button, a Listbox or a Canvas. Widgets can be displayed on a X window server. The user can graphically interact with a widget, like entering text or selecting an entry. Several widgets allow binding events, which enables programmers to introduce a variety of interaction between the user and the program.

Scalars are the most simple data type in Perl. They are marked by a “$” character and can take any information, like $x=3; $y=-4.78e-24; $string=”hello world”;

Lists or Arrays are collections of scalars. The are marked by a “@” character. Examples are @list=(1, 2, 3, 4); @names=(“charly brown”, “snoopy”); @joined=( “hello world”, @list, @names); Lists are accessed via their integer index.

Hashes are lists of key/value pairs. In contrast to Arrays they are accessed via arbitrary keywords, like a mini-database. Hashes are marked by the “%” character, like %names=( “fred”=>”flintstone”, “charly”=>”brown” );

The given example creates a new Window on the screen, which contains only one Button. The Button is named “Cancel”. Once it is hit, the program will terminate and the Window will disappear.

#1 When executing this file the command shell looks for the shebang-operator “#!” in the first line to find out, which other program should be started to interpret this file. In this case it is “Perl”, which can be found in the directory “/usr/bin” on the specified system. The flag “-w” notifies Perl to issue warnings.

#2. Notify Perl to include the “Tk”-module to create a GUI.

#4. A comment line.

#5 “MainWindow” is a Perl/Tk-widget. A new instance of this widget is created and its memory address is assigned to the “$mw” variable.

#9 A “Button”-widget is created. It is linked to the $mw-variable. As a result this Button will appear only in the window indicated by $mw.

#10 Assigning a specific text to the Button.

#11 Assigning a command to the Button. When this Button is hit, the specified program is called. In this example the subroutine is so short that it is included here. Simply, the Perl/Tk specific exit() routine is called.

#12 Pack() determines where the widget will occur in the MainWindow later on. When creating several widgets they will be displayed in their order from the source code.

#14 Now all visual properties and events of the Window are defined. Perl/Tk enters an endless loop to allow event handling. Once the MainLoop has been entered the Window and its widgets will become visible on the screen.

A preliminary Compilation of Perl-Fields

Perl provides a very high degree of functionality for data processing. Reference [4] is scanned incompletely for a first set of Perl-fields. Where necessary the page is specified below. The idea of this list is to guide a Perl specialist to the required or available resources, when solving inventive problems in a Perl program with TRIZ. A Perl-novice may want to have a look at reference [7] first, where most of the resources listed below can be found as well.

Similar Field/Resource lists can be derived for other computer languages, like C, Pascal, Fortran, Basic, C++ or Smalltalk. The overwhelming amount of available fields, resources and effects from other Perl-modules are not included [5].