TModel is a fundamental component of the program, responsible for the functioning of the model as a whole. With  TModel we can initiate and pause the simulation, process  or clear statistics collected in blocks. Another useful feature of TModel is the ability to monitor transactions and fix moments in which time changes occur. For each Delsi application there can be only one TModel.


TScheduler is intended to initiate the events throughout various intervals of the simulation time. It is primarily need to control the simulation process. By using this component, the user can  alter model parameters, stop the simulation, clear statistics or lock/unlock gates.


TGenerator produces a single transaction during each activation. The user may utilize this function when simulating the arrival of served elements within the program. In most cases, the arrivals have some intensity described through probability distribution. For simulating sequential arrivals, when the transaction leaves the generator we need to order the next activation, i.e. the next transaction generation. Appropriating a value ActivationTime random numbers, we simulate statistical properties of arrival intensity.



This component simulates simple FIFO queue. It handles transactions in accordance with the rule “First input – first output”. The queue may be limited by capacity. Another useful feature is the ability to limit the waiting period within a queue. If the number of transactions in the queue is less than its capacity, the queue is in the state “Ready to Receive”. If the queue keeps one or more transactions, it is in the state “Ready to Give”. Ordering the next activation in the queue you can limit the waiting period for the transaction.


This component simulates simple LIFO queue. It handles transactions in accordance with the rule “Last input – first output”. Besides, this component repeats all properties, methods and events of TQueue.



TQueuePrty differs from TQueue by the discipline of transaction keeping. It keeps them in accordance with the rule “First input – first output in its priority level”. So, the transactions with higher priority will leave the queue first.
Another distinguishing feature of TQueuePrty is the following. Let’s imagine that the queue is full, i.e. the number of transactions is equal to the queue capacity, and a transaction tries to enter into the queue. Assume that this transaction has preemptive priority with the level higher than the lowest priority of transactions in the queue. In this сase high-priority preemptive transaction will displace the lowest- priority transaction. This operation is called  preempting. Preempted (diplaced) transactions may be passed to other blocks or terminated depending on handling procedure of OnPreempt event.


TServer simulates a serving process. In every moment of time only one transaction can be served only. The transaction is served during the time defined by the method NextTime in the procedure of handling OnEnter event.
As TQueuePrty component, TServer can handle preempting. Preemptive high-priority transaction preempts the serving low- priority transaction. The preempted transaction may be passed to another block or terminated. The third alternative is that the serving preempted transaction may be postponed. When a high-priority transaction leaves the server, the postponed transaction will be reset on serving for the rest of service time.  The server can store only one postponed transaction per priority level. Postponed transactions are kept in the stack ordered by priority. Note, that there is a difference between number of transactions which is being served (may be 0 or 1) and the number of transactions in the server (may be equal up to number of priority levels in our model).



TStorage may be described as a server able to serve several transactions simultaneously. It is a simple storage, which does not support preempting.


Additionally to the possibilities of TStorage, this component supports priority preempting. The preempting in TStoragePrty is similar to preempting in TQueuePrty and TServer. As well as  TQueuePrty, TStoragePrty does not support the postponed service.



Transactions enter into this block to be terminated. When you handle OnEnter event, the transaction is still accessible and you have an opportunity to get some information about it. TTerminator is always “Ready to Receive”.


Splits the arrived transaction into several ones. The new transactions have the same priority and ability to preempting, as their parent. Divider emits transactions thus that the transaction- parent will go last. This block is “Ready to Receive” and “not Ready to Give”, if it is empty. If it is not empty, it is “not Ready to Receive” and “Ready to Give”.



TAssembler assembles several arrived transactions into one. Actually, the first input transaction remains in alive. The rest of the transactions will be terminated. This block is “Ready to Receive” and “not Ready to Give” until the resulting transaction is assembled. When the transaction is assembled, TAssembler is “not Ready to Receive” and “Ready to Give”.


Creates transactions on demand. After creation of transactions the component “is Ready to Give” as long as transactions are being emitted. In a combination with TScheduler you can simulate the generator, which produces portions of the transactions.



This block is a simple gate. You can lock, unlock and inverse the gate. If gate is unlocked it works like a simple server with zero service time.  By locking the gate you discontinue promoting of the transactions that go through it.


This component is not an aggregate. It is designed for statistical purposes only. If you need to build a histogram of some output parameter, this component helps you to calculate the hits of its values in numerical intervals. Beside that, TTabulator calculates the average value of the parameter and its standard deviation.



This component is intended to generate random variates of different distributions: