Dear visitors!
I am an author of system Hierarchic GPSS.
The PhD, Professor Anatoly Korolyov from Ukraine.
I have been researching simulation systems such as GPSS since 2002 and I have wide experience in C# programming.
I have created system which allows building models in GPSS style using C# language. Each model is created as the executable which one can run and receive simulation results. Visualization features are minimal though.
Hierarchic GPSS supports wide array of standard C# features, such as arrays of objects, text files, variables, structures, tables etc. My system also provides flexible management of the future events for transactions and allows building the general model using separate model segments.
In my opinion, the concept of the future incorporated in GPSS is very conservative and reminds directive planning in the totalitarian states. I mean the transactions detained in Advance practically are not accessible by the system for redefinition of their future. The exceptions are single transactions with known numbers. Systems such as GPSS don’t have features to work with transactions from the list of the future events.
In Hierarchic GPSS, the list of the future events is the successor of the user list and transactions management from the list of the future events is simple and natural, as well as transactions management from the list of the user.
As a matter of fact, models in Hierarchic GPSS can have several lists of the future events - this provides greater flexibility.
It is rather difficult to use hierarchical techniques of model construction in GPSS which has proved the efficiency in other areas of development of the software.
Because of the absence of hierarchy visualization of models in GPSS, the big models in GPSS are generated by special shell programs. In GPSS it is impossible to develop fragments of models "for the future" i.e. to use them in the future models if required.
The final model in Hierarchic GPSS can be constructed from separately described and even pre-compiled model segments. One segment is the main segment and it initiates, if necessary, availability for service of other segments. All model segments have potentially identical structure and opportunities. The only exception is the simulation plan which should be located in the main segment only.
The block Jump is used for transition of transaction from one segment to another: Jump (<segment number >, <entrance point >, <return parameters >). If block simply returns from a segment - return parameters are optional. The place of return is stored in P-parameters as segment number and a point of return to a segment. Numerical values and object references (devices, queues, tables, methods etc.) can be specified for transaction.
Parts of model segments can be pre-compiled – this allows development and distribution of model segments as libraries expanding and facilitating new models development. The user of the system can also create new standalone segments which will allow developing and modernizing models fast and more effectively. This is especially important when developing model in connection with changes in a subject domain. The system collects statistics on blocks for all segments if it is enabled in the segment.
If my system is interest for you please contact me objectgpss@yandex.ru
Best regards,
Anatoly.
