{'fraction_non_alphanumeric': 0.019402985074626865, 'fraction_numerical': 0.004477611940298508, 'mean_word_length': 5.2372093023255815, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Petri nets for modelling fault tolerant distibuted systems in a modular and incremental way

In his paper 'Beyond Programming Languages' T. Winograd [1] claims that for modelling complex systems sometimes one needs a temporary suppression of details. In particular, he focuses his attention on the need of a clear distinction between the "normal" behaviour of a system, and its more complex behaviour for handling exceptions and possible faults. That is, the relative simplicity of the specification of the first one should not be overloaded with all the details necessary for handling erroneus situations. We also have realized recently the usefulness of such guidelines when we have undertaken the specification and modelling of some case studies in the framework of the ESPRIT BRA #3148 DEMON (DEsign Methods based On Nets). The considered systems [2] are composed of distributed components which synchronize their behaviour to do the job: examples are a Telephon Switching System, a Flexible Manifacturing System, the Lift and the Distributed Termination Problem. Once more we have found that the problem descriptions in general mix the specification of the routine (or normal or standard) cases with the specification of some exceptions and with the requirement of handling possible faults of some system components. This mix makes the