now , the present invention will be described in greater detail by referring to the accompanying drawings that illustrate preferred embodiments of the invention . in the description of this embodiment , it is assumed that a mutex lock is used as synchronizing mechanism and there is a data race between the shared variables as a result of an alteration made to a program . fig1 is a schematic block diagram of a program verification apparatus according to the invention , showing the configuration thereof as an example . this program verification apparatus comprises an alteration detecting section 11 , a source code sorting section 12 , a model generating section 13 and a verifying section 14 . firstly , the operation of a program verification apparatus according to the invention will be described in terms of the first program to be verified as a specific example of parallel program . the source code of the first program to be verified comprises a definition of a shared variable , a function process 1 and another function process 2 . fig2 is a schematic illustration of the source code showing the definition of the shared variable in the first program to be verified . fig3 is a schematic illustration of the source code showing the function process 1 before an alteration in the first program to be verified . fig4 is a schematic illustration of the source code showing the function process 2 in the first program to be verified . fig5 is a schematic illustration of the source code showing the function process 1 after an alteration in the first program to be verified . as seen from the figures , there is a data race involving the shared variable shared 1 between the function process 1 and the function process 2 when the function process 1 is altered . fig6 is a flow chart of an example of operation of the program verification apparatus according to the invention . firstly , the alteration detecting section 11 executes an alteration detection process of reading the program before the alteration and the program after the alteration and checking the difference between them ( s 11 ). fig7 is a flow chart of an example of operation of an alteration detection process according to the invention . firstly , the alteration detecting section 11 compares the program before the alteration and the program after the alteration and identifies function j that was altered and the set of shared variables v that was influenced by the alteration ( s 21 ). then , the alteration detecting section 11 adds a mark to the part where set of shared variables v appears and the locked part in function j after the alteration ( s 22 ). thereafter , the alteration detecting section 11 adds a mark to the part where the set of shared variables v appears and the locked part in function j before the alteration ( s 23 ). subsequently , the alteration detecting section 11 identifies function k where the set of shared variables v appears from the other function ( s 24 ). then , the alteration detecting section 11 adds a mark to the part where the set of shared variables v appears and the locked part in the function k ( s 25 ). thereafter , the alteration detecting section 11 output the marked set of functions ( s 26 ) and ends the process . now , a specific example of alteration detection process will be described below . fig8 is a schematic illustration of a source code showing as an example the results of an alteration detection process of function process 1 after an alteration in the first program to be verified . referring to fig8 , firstly the alteration detecting section 11 identifies the function process 1 as the only function that is altered and also the part where of the function process 1 that is altered and subsequently adds marks “// 1 ” through “// 6 ” to the identified part . the alteration detecting section 11 identifies shared variable shared 1 as the shared variable that is used at the altered part . fig9 is a schematic illustration of a source code showing as an example the results of an alteration detection process of function process 1 before an alteration in the first program to be verified . then , the alteration detecting section 11 identifies the part of the process 1 where shared 1 appears before the alteration and adds mark “// s ” to the identified part . fig1 is a schematic illustration of a source code showing as an example the results of an alteration detection process of function process 2 in the first program to be verified . then , the alteration detecting section 11 retrieves another process that uses variable shared 1 , identifies function process 2 and also the part where shared 1 appears in the function process 1 and adds mark “// s ” to the identified part . as a result , the output of the alteration detecting section 11 is a set of the function process 1 before the alteration , the function process 1 after the alteration and the function process 2 and the source code where marks are added to the altered parts and the parts influenced by the alterations . subsequently , the source code sorting section 12 sorts the control structure , the part that is influenced by an alteration and the remaining part ( s 12 ). the source code sorting section 12 sorts out sentences on a basic block by basic block basis , leaving the control structure and the marked sentences unsorted . a basic block is a block defined for compiler techniques and refers to a block having only an entrance and an exit for a control flow . fig1 is a flow chart of an example of operation of a source code sorting process according to the invention . referring to fig1 , firstly the source code sorting section 12 takes out a function j from a set of functions that is an output of the alteration detecting section 11 ( s 31 ). then , the source code sorting section 12 extracts the control structure from the function j and outputs it to a new extracted function j ′ ( s 32 ). thereafter , the source code sorting section 12 extracts the marked part from the function j and outputs it to the extracted function j ′ ( s 33 ). subsequently , the source code sorting section 12 sorts out the unmarked parts from the function j , extracts them on a basic block by basic block basis and outputs them to the extracted function j ′ ( s 34 ). then , the source code sorting section 12 determines if any unprocessed function is left in the set of functions or not ( s 35 ). if an unprocessed function is left ( s 35 , y ), it returns to the processing step s 31 . if , on the other hand , there is not any unprocessed function left ( s 35 , n ), it outputs the set of extracted functions j ′ as set of extracted functions ( s 36 ) and ends the flow . now , the source code sorting process will be described by way of a specific example . fig1 is a schematic illustration of a source code showing as an example the results of a source code sorting process of function process 1 before an alteration in the first program to be verified . the basic blocks of function process 1 before an alteration are sorted as pseudo - function aa ( ), pseudo - function bb ( ), pseudo - function cc ( ), pseudo - function dd ( ) and pseudo - function ee ( ). fig1 is a schematic illustration of a source code showing as an example the results of a source code sorting process of function process 2 in the first program to be verified . the basic blocks of function process 2 are sorted as pseudo - function xx ( ) and pseudo - function zz ( ). fig1 is a schematic illustration of a source code showing as an example the results of a source code sorting process of function process 1 after an alteration in the first program to be verified . the basic blocks of the function process 1 after the alteration can be sorted by sorting function a ( ) and function b ( ) as pseudo - function a ( ), function d ( ) as pseudo - function b ( ), function e ( ) as pseudo - function c ( ), function i . lock ( ) through function f ( ) as pseudo - function d ( ) and function h ( ) as pseudo - function e ( ). then , the model generating section 13 transforms the result of the source code sorting process into a model ( s 13 ). the type of the model may vary depending on the technique used in the verification process as will be described hereinafter , a model check is used for the verification process of this embodiment and an fsm is used as model . the model generating section 13 allocates the states of the results of the source code sorting process on a basic block by basic block basis or on a block by block basis for referring to a shared variable and additionally realizes state optimization . state optimization is a process of sorting states that do not contain any marked part as a single state . it can be realized by applying the state minimization algorithm . fig1 is a flow chart of an example of operation of a model generation process according to the invention . referring to fig1 , firstly the model generating section 13 takes out an extracted function j ′ out of a set of extracted functions that is the output of the source code sorting section 12 ( s 41 ). then , the model generating section 13 regards the part protected by a lock as basic block ( s 42 ). thereafter , the model generating section 13 traces the control structure of the extracted function j ′ and takes out a basic block ( s 43 ). subsequently , the model generating section 13 determines if there is any marked part in the basic block or not ( s 44 ). if there is at least a marked part ( s 44 , y ), the model generating section 13 separates the marked part from the basic block and allocates it to a state ( s 45 ), while it allocates the remaining parts to respective states ( s 46 ) and proceeds to the processing step s 48 . if , on the other hand , there is not any marked part ( s 44 , n ), the model generating section 13 allocates the basic block to a state ( s 47 ) and proceeds to the processing step s 48 . then , in the processing step s 48 , the model generating section 13 determines if any unprocessed basic block is remaining or not ( s 48 ). if at least an unprocessed basic block is remaining ( s 48 , y ), it returns to the processing step s 43 . if , on the other hand , no unprocessed basic block is remaining ( s 48 , n ), the model generating section 13 realizes state optimization ( s 49 ). thereafter , the model generating section 13 determines if any unprocessed extracted function is remaining in the set of extracted functions ( s 50 ). if at least an unprocessed extracted function is remaining ( s 50 , y ), it returns to the processing step s 41 . if , on the other hand , no unprocessed extracted function is remaining ( s 50 , n ), the model generating section 13 outputs the results of state optimization as a set of fsm models ( s 51 ) and ends the flow . now , a specific example of model generation process will be described below . firstly , the results of state allocation down to the processing step s 48 will be described . fig1 is a schematic illustration of a model , showing as an example the results of state allocation in a model generation process of function process 1 after an alteration in the first program to be verified . the model generating section 13 allocates pseudo - function a ( ) and function c ( ) as state a , pseudo - function b ( ) as state b , pseudo - function c ( ) as state c , pseudo - function d ( ) as state d , pseudo - function e ( ) as state e , “// 1 ”, “// 2 ” and “// 3 ” as state n 123 and “// 4 ”, “// 5 ” and “// 6 ” as state n 456 respectively . now , the results of state optimization in the processing step s 49 will be described below . fig1 is a schematic illustration of a model , showing as an example the results of a model generation process of function process 1 after an alteration in the first program to be verified . here , state a , state b , state c and state d become a single basic block and , since there is not any marked part in it , they are integrated to state a ′. in a similar manner , the model generating section 13 executes a model generation process on function process 1 and function process 2 before an alteration . fig1 is a schematic illustration of a model , showing as an example the results of state allocation in a model generation process of function process 1 before an alteration in the first program to be verified . pseudo - function aa ( ), pseudo - function bb ( ), pseudo - function cc ( ), pseudo - function dd ( ) and pseudo - function ee ( ) are allocated respectively to state aa , state bb , state cc , state dd and state ee and the part that is marked with “// s ” is allocated to state n 1 . fig1 is a schematic illustration of a model , showing as an example the results of a model generation process of function process 1 before an alteration in the first program to be verified . state aa , state bb , state cc and state dd become a single basic block and integrated to state aa ′ because there is not any marked part in it . fig2 is a schematic illustration of a model , showing as an example the results of a model generation process of function process 2 in the first program to be verified . pseudo - function xx ( ) and pseudo - function zz ( ) are allocated respectively to state xx and state zz and the part that is marked with “// s ” is allocated to state n 2 . no change takes place as a result of state optimization . then , the verifying section 14 executes a verification process , using the results of the model generation process ( s 14 ). while techniques that can be used for a verification process include model check and rule base check , the model check technique is used for the verification process in this embodiment . fig2 is a flow chart of an example of operation of a verification process according to the invention . referring to fig2 , firstly the verifying section 14 performs a model check operation on the altered functions in the set of fsm models output from the model generating section 13 ( s 61 ) and determines if the models are equivalent or not ( s 62 ). if the models are equivalent ( s 62 , y ), the verifying section 14 proceeds to processing step s 68 . if , on the other hand , the models are not equivalent ( s 62 , n ), the verifying section 14 extends the range of functions to be verified and performs a model check operation ( s 63 ) so as to determine if the models are equivalent or not ( s 64 ). if the models are equivalent ( s 64 , y ), the verifying section 14 proceeds to processing step s 68 . if , on the other hand , the models are not equivalent ( s 64 , n ), the verifying section 14 displays the part that is a problem ( s 66 ). then , if possible , it adds a restriction to the operation of the program and , if necessary , inserts assertion according to the direction of the designer ( s 67 ). then , it returns to processing step s 63 . in processing step s 68 , the verifying section 14 displays that there is not any problem due to the alteration ( s 68 ) and ends the flow . in the verification process , the model before an alteration and the model after the alteration are compared for a function that is altered and a model check operation is conducted . if the models are found to be equivalent as a result of the verification process , the altered part is guaranteed to behave just like before the alteration and hence it is possible to guarantee that the program does not have an error as a whole . if , on the other hand , the models are not equivalent , the program can have an erroneous behavior and hence the range of functions to be verified is extended and the functions that are detected in the alteration detection process are verified in addition to the altered functions . if no error is found as a result , it is possible to guarantee that the program does not have an error as a whole . a product of states is prepared by taking the partial order relation of the models of the functions in order to extend the scope of verification and express the mutual influence of a plurality of functions that operate concurrently and in parallel . then , the product of states is subjected to verification with an extended scope . a known algorithm is used to obtain the product of states . such algorithms are described in detail in berard , b ., bidoit , m ., finkel , a ., laroussinie , f ., petit , a ., petrucci , l ., schnoebelen , p . “ systems and software verification model — checking techniques and tools ”, springer - verlag , 2001 . if a problem is found as a result of the verification process , a trace generation process of outputting the sequence of execution , for example , will be an effective means for showing the cause of the error in the processing step s 66 . fig2 is a flow chart of an example of operation of a trace generation process according to the invention . an fsm and the property to be verified are input to the trace generation process . in this embodiment , the property to be verified is checking if a deadlock or a data race exists or not . firstly , the verifying section 14 searches for a state that satisfies the property to be verified in the fsm sequentially from the initial state ( s 71 ) and determines if there is a state that satisfies the property to be verified ( s 72 ). if there is not any state that satisfies the property to be verified ( s 72 , n ), the verifying section 14 determines that neither a deadlock nor a data race takes place ( s 73 ) and ends the flow . if , on the other hand , there is a state that satisfies the property to be verified ( s 72 , y ), the verifying section 14 outputs the sequence of execution from the initial state to the state that satisfies the property as trace ( s 75 ) and ends the flow . if the scope of verification is extended again , it is possible for the designer to execute the verification process after defining restrictions on the operation of the program in the processing step s 63 . when the designer inputs them to the source code as assertion , it is easy to detect the part , if any , that does not observe the restrictions when conducting a test after the end of the debugging operation . now , a specific example of verification process will be described below . in this example , firstly , the model of function process 1 before an alteration and the model of function process 1 after the alteration are compared . since the models are not equivalent as a result , an error can occur . therefore , the verification process is conducted once again . this time , function process 2 that can be influenced by the alteration of function process 1 is included . then , as a result , it is detected that an error will occur and that an error will occur in the next step of execution . the verifying section 14 displays the outcome of detection . reading variable shared 1 ( invoking function g ) from and writing it to function process 1 before an alteration is protected by a lock so that it is not interrupted ( preempted ) by function process 2 . additionally , when function process 2 is protected by a lock , the value of shared variable shared 1 is incremented without fail after the function g of the function process 1 is invoked . on the other hand , when the sequence of execution using function process 1 after an alteration does not meet the specified requirements , both state n 123 ( invocation of function g ) and state n 456 ( writing variable shared 1 ) are protected by a lock . state n 2 ( region protected by the lock ) of function process 2 is executed in between state n 123 and state n 456 . because lock l is released after the read of variable shared 1 in state n 123 , there is no guarantee that the value of variable shared 1 will not be modified before lock l is acquired again in state n 456 . the value of variable shared 1 is not incremented when state n 2 is executed . therefore , the behavior is different from the behavior before the alteration . such a behavior can be corrected when the designer defines restrictions . in the case of this program , no error occurs when an interruption ( preemption ) to state n 2 of function process 2 is prohibited while function process 1 is in state n 123 , state e or state n 456 . this embodiment will be described below in terms of a deadlock that takes place when the sequence of synchronizing mechanism for arbitration of accesses to a shared variable is changed . the verification apparatus of this embodiment has a configuration similar to that of the first embodiment . the operation of the verification apparatus will be described in the case of using the second program to be verified , which is a specific example of parallel program . the source code of the second program to be verified comprises a definition of a shared variable , a function process 3 and another function process 4 . fig2 is a schematic illustration of the source code showing the definition of the shared variable in the second program to be verified . fig2 is a schematic illustration of the source code showing the function process 3 in the second program to be verified . fig2 is a schematic illustration of the source code showing the function process 4 before an alteration in the second program to be verified . fig2 is a schematic illustration of the source code showing function process 4 after an alteration in the second program to be verified . as shown in fig2 , the function process 4 is altered for the locking sequence . as a result of this alteration , the locking sequence of the function process 3 and that of the function process 4 differs from each other when accessing the shared variable . fig2 is a schematic illustration of the source code showing as an example the results of a source code sorting process of function process 4 after an alteration in the second program to be verified . then , pseudo - function d ( ) and pseudo - function f ( ) are allocated respectively to state d and state f by means of a model generation process . the region ( marked by “// e ”) that is protected by a lock is regarded as basic block and a state unfolding process is executed . in other words , in this embodiment , the following state unfolding process is executed in place of the above described processing step s 45 in a model generation process . fig2 is a flow chart of an example of operation of a state unfolding process according to the invention . referring to fig2 , firstly the model generating section 13 determines if there is a plurality of locks in a part of the basic block that is marked and separated in the processing step s 45 or not ( s 81 ). if there is not a plurality of locks ( s 81 , n ), the model generating section 13 allocates a marked state to a state ( s 82 ) as in the processing step s 45 and output an altered fsm model ( s 83 ) before it ends the flow . if , on the other hand , there is a plurality of locks ( s 81 , y ), the model generating section 13 allocates the states that the locks can take to the fsm ( s 85 ) and also the operation protected by the locks to a state ( s 86 ), makes the locks and the state of transition of the operation matches the control flow of the original basic block ( s 87 ) and then outputs the altered fsm model ( s 88 ) before it ends the flow . in processing step s 83 , the model generating section 13 allocates the states of the fsm to the states that the locks can take . as a result , the four states as listed below are allocated in function process 4 . state n 10 . acquisition of lock m before operation state n 20 . acquisition of lock l before operation and after acquisition of lock m state n 30 . release of lock l immediately after operation state n 40 . release of lock m after operation and the release of lock l the operation is allocated to a state in processing step s 84 . in this case , a state is allocated between the state n 20 and the state n 30 listed above to produce the following five states . state n 10 . acquisition of lock m before operation state n 20 . acquisition of lock l before operation and after acquisition of lock m state n 25 . operation state n 30 . release of lock l immediately after operation state n 40 . release of lock m after operation and the release of lock l fig2 is a state transition diagram showing as an example the results of a model generation process of function process 4 after an alteration in the second program to be verified . referring to fig2 , state l ( u ) refers to a state where the lock l is unlocked , state l ( 3 ) refers to a state where function process 3 acquires the lock l and state l ( 4 ) refers to a state where function process 4 acquires the lock l , whereas state m ( u ) refers to a state where the lock m is unlocked , state m ( 3 ) refers to a state where function process 3 acquires the lock m and state m ( 4 ) refers to a state where function process 4 acquires the lock m . additionally , when a plurality of function is verified as objects of verification , it is expressed by the product of states . the state l ( u ) m ( 4 ) through the state l ( u ) m ( u ) in fig2 correspond to the state n 10 through the state n 40 . the fsm of function process 3 and that of function process 4 before an alteration can be obtained by following a similar sequence . fig3 is a state transition diagram showing as an example the results of a model generation process of function process 3 in the second program to be verified . fig3 is a state transition diagram showing as an example the results of a model generation process of function process 4 before an alteration in the second program to be verified . then , the function process 4 after an alteration is not equivalent with the function process 4 before the alteration in processing step s 61 of the verification process . therefore , the range of functions to be verified is extended to include function process 3 for verification . to verify the influence of function process 3 and function process 4 that operate concurrently , the product of states of the two functions is prepared by taking the partial order relation and the product is verified . as a result of this model checking operation , it is found that the sequence of execution as shown below leads to a deadlock . the cause of the deadlock is that function process 4 acquires lock m ( state l ( 3 ) m ( 4 )) after function process 3 acquires lock l ( state l ( 3 ) m ( u )). thus , the lock l and the lock m are acquired respectively by the function process 3 and the function process 4 . if the function process 3 tries to acquire the lock m , the process comes to a standstill because the function process 4 has already acquired it . similarly , if the function process 4 tries to acquire the lock l , the process comes to a standstill because the function process 3 has already acquired it . in this case , the alteration has to be undone in order to correct the error . as described above in detail , according to the invention , it is possible to remarkably reduce the time required for verification by preparing models , paying attention to the shared resources and the locks that are influenced by an alteration to a concurrent / parallel program . furthermore , according to the invention , there is provided a program for verifying a program that causes a computer that operates as a program verification apparatus to execute the above described processing steps . more specifically , it is possible to cause a computer that operates as a program verification apparatus to execute such a program when the program is stored in a computer - readable recording medium . computer - readable recording media that can be used for the purpose of the present invention include internal storage devices such as roms and rams that are installed in computers , portable type storage media such as cd - roms , flexible disks , dvd disks , magneto - optical disks and ic cards , and databases for holding computer programs as well as other computers , their databases . for the purpose of the present invention , a detection step corresponds to the alteration detection process and the source code sorting process of the above - described embodiments . a model generation step corresponds to the model generation process of the above - described embodiments . additionally , a verification step corresponds to the verification process of the above - described embodiments and a verifying section corresponds to the alteration detecting section and the source code sorting section of the above - described embodiments .