Test Knowledge in SHAKEN

(7/24/01)

 

 

 

 

SHAKEN simulates your process model and checks several things:

For each of these checks, SHAKEN will report:

For each error or warning, you can ask SHAKEN to show you a list of suggestions for how to fix them. You can pick one of these suggested fixes, or you can decide to fix the problem in a different way. SHAKEN will take you to the knowledge editor window in either case.

 

 


 

1. CHECKING CONDITIONS AND EFFECTS

 

The conditions (or preconditions) of an event express what needs to be true or satisfied in order for a step to be carried out.  The effects of an event describe what is achieved after the event happens, some effects show what is added or made true and some effects show what is deleted or made false after the step is executed.  SHAKEN checks the conditions and effects of the events that you have defined and alerts you of any errors or potential problems with the knowledge you have entered in SHAKEN.

 

Please note you can see the conditions and effects of a component in the library by selecting “Description” mode in the “Inspecting Concept” window.  For example:

     the Move

                    Conditions: the Polymerase mustn’t be restrained.

          The following conditions will become false:

the location of the Polymerase is the Place. 

          The following conditions will become true:

the location of the Polymerase is the Stop-Site. 

                   

 

 

 

 

1.1.        Checking conditions:

 

1.   Check if the conditions of each step are satisfied.

Example condition:  For a Sigma-Release step, the Sigma Factor must be confined.

2.   If a condition does not seem to be true, check if we can safely assume that the condition was true before the process started:

            If SHAKEN can assume that the condition is true, it will show you a warning:

Note: You never told me the following conditions were true, but we can safely assume that they are true:

The location of the Virus is near the Cell.

                  If we cannot assume the condition was initially true, then a previous step probably had an effect that made it false.  SHAKEN will show you an error:

The Sigma Factor must be confined.

This condition failed.

 

 

       After showing you this error, SHAKEN will show you some proposed fixes.  Fixes describe what you can do to change your knowledge in order to fix this error.  SHAKEN shows first general kinds of fixes, such as:

        Add a new step that can achieve the failed condition.

        Modify previous steps so that they achieve the failed condition.

        Check if some previous steps delete the condition, then change the
ordering so they occur after the current step.

        Check the role assignments of the current step.

        Modify the current step.

 

SHAKEN will follow-up with more specific suggestions, for example what kinds of events you can choose from the component library that you can add as new steps to achieve the condition.

 

      Example:


Fixes for Bact-Txn2

Unachieved condition: the Sigma-Factor must be confined to the base of the Sigma-Release.

Suggestions:

There are several things that one can do in order to fix this kind of problem, such as:

[apply  fix] Add steps that can achieve the failed condition.

[apply  fix] Modify previous steps so that they achieve the failed condition.

[apply  fix] Check if some previous steps delete the condition, then change the
                   ordering so they occur after the current step.

[apply  fix] Check the role assignments of the current step.

[apply  fix] Modify the current step.

       These are more specific suggestions:

[apply  fix] Add a step.

Step details:  A Confine

Step Order: Before the Sigma-Release

Effect of the step: The object-of of the Sigma-Factor becomes a Be-Confined.

      ….

[apply  fix] Modify the object-of of the Sigma-Factor.

[apply  fix] Modify or delete the Sigma-Release the object-of.

     [none of above]  None of the fixes above seem appropriate in this case. The knowledge will be modified in a different way than what is suggested above.

 

 


 


1.2. Checking Effects:

 

1.   Check what happens after each step is executed in terms of what effects are added (things that become true) and deleted (things that become false). 

         Example:

 


         Step: Move-To

Checking effects:

The following becomes false:

1.      The location of the object of the Move-To is the Place.

The following becomes true:

1.      The location of the object of the Move-To is the Stop-Site.

….

 


2.  Check if each step produces any effect.

            Example: No effect was produced by the Move step.


Suggested fixes:

o       Modify the role assignments of the step.

o       Modify the step.


1.3. Checking undeletable assertions:

 

A step tries to delete an assertion that is not true in the current situation.

 

Suggested fixes:

o       Modify the role assignments of the step.

o       Modify previous steps to assert the condition.


 

1.4. Checking Expected Effects:

 

You can tell SHAKEN what you expect to be the case after the overall process happens (expected effects).

Examples of expected effects:

SHAKEN will check that these things are true at the end of the simulation. If SHAKEN reports that they are not, that is a sign that your process model is not defined as you expected and you need to go back and correct it.

 

 

      Example of failed expected effect:

 


Checking expected effects of the overall process:

The location of the Viral-Nucleic-Acid must be at the location of the Cytoplasm.

              Expectation failed.

 

 



Suggested fixes:

o       Add steps that can achieve the effect.

o       Modify previous steps so that they achieve the effect.

o       Check the ordering among the steps to see if some previous steps undo
the condition.

 


2. CHECKING STEP ORDERING

 

2.1. Checking missing first-subevent of a step:  

 

A step has subevents but its first-subevent is not specified.

 

      Example:

 


Checking first-subevent:

Error: I don't know which one of these is the first subevent of Transcription.

1.        the RRNA-Tx

2.        the MRNA-Tx

3.      the TRNA-Tx



Suggested Fixes:

o       Specify the first-subevent of the event.

 

 

2.2. Checking missing subevent link of a step:  

 

A step has first-subevent but the first-subevent is not a subevent.

 

      Example:

 


Checking missing subevent link:

Error: the Transcription is the first-subevent of the Protein-Synthesis but not its subevent.



Suggested Fixes:

o       Make the first-subevent a subevent of the event.

 

 

 

 

2.3. Checking unreached steps:  

 

     When the next-subevent ordering among substeps is not correct, some steps cannot be simulated.  SHAKEN will report any steps unreached during the simulation.

 

      Example:

 


Checking unreached steps:

Note: These steps were not executed due to missing ordering constraints.

1.        the TRNA-Tx

2.        the MRNA-Tx

3.        the RRNA-Tx

 



Suggested fixes:

o    Add or modify next-event/subevent/first-subevent links among the steps so that they refer to the unreached steps.

 

2.4. Checking parallel steps:  

 

     Sometimes events are supposed to happen in parallel at the same time. This is indicated when there are several first-event links and several next-event links for a step.  SHAKEN checks if there are any inconsistencies with your specification of sequential events (next-step) and parallel events.

 

      Example:

                                                               

Checking ordering between parallel events:

Error: I expect that the Transcription and the Produce are parallel because they are both the first-subevents but there is an ordering between them: the Transcription before the Produce.


Suggested fixes:

o  Modify or delete next-event links between the parallel events.

o  Modify or delete first-subevent links.

 

 

2.5. Checking loops:  

     

     SHAKEN checks if there are any loops among subevents, and warns you if it finds any so you can confirm that it was intended.


Suggested fixes:

o    Modify or delete next-event links among the steps involved in the loops.

 

 

2.6. Checking unnecessary links:  

     

     The definitions of events in the component library include conditions and effects of each kind of event.  When a substep goes before another one it is typically because it achieves something needed by the later step.  SHAKEN checks the definitions in the component library and warns you if the ordering among the substeps seem to be unnecessary.

      Example:

                                                               

Checking specified order of steps:

Note: These requirements seemed to be unnecessary given the definitions currently I have about those steps:

1.        DNA-Melting before Copy called Transcribe: DNA-Melting does nothing that Copy called Transcribe needs.

2.        Copy called Transcribe before Sigma-Release: Copy called Transcribe does nothing that Sigma-Release needs.

3.        Sigma-Release before Move-To: Sigma-Release does nothing that Move-To needs.

           
Suggested fixes:

o    Modify or delete next-event links

 

 

3. CHECKING ROLE ASSIGNMENTS

 

3.1. Checking role assignments:  

     

     Check if there are roles of an event that require having an object assigned to them and have no objects assigned. 


Suggested fixes:

o    Specify role value of the object.

 

 


4. Other simulation results

 

 4.1. Simulation paths

 

This shows all the possible alternative sequences of subevents that are possible given what you have specified.

 

4.2. Steps that enable other steps to take place  

              

Check and show what steps cause effects that enable other steps to happen.  This is another way of checking the conditions and effects of each step.

 

Step A enabled B because step A produces effects that achieve a condition of step B. 

 

      Example: The Hold step enabled the Carry step because after Hold, The agent of the Be-Held becomes the Organism called Horse.