Este artículo describe los nuevos componentes del marco para la simulación, previamente presentado en el artículo
"Un sistema simple de simulación en marcha" . A medida que el marco se expandió, se hizo posible modelar sistemas más complejos, por ejemplo, para simular el trabajo de un restaurante.
Nuevos componentes
Hay varios componentes nuevos:
bifacilidad ,
división ,
agregado ,
recuento ,
asignación ,
verificación . Consideremos con más detalle.
Bifacility es esencialmente lo mismo que
Facility , pero su propósito es hacer que la transacción ocupe no solo un componente por un tiempo, sino una cadena de componentes. Para esto, el constructor
Bifacility forma dos componentes: IN y OUT. Después de que una transacción
ingresa al componente IN,
Bifacility se considera ocupada y otra transacción ya no puede tomarla. Cuando una transacción golpea el componente OUT,
Bifacility se libera y ahora otra transacción puede tomarlo. Solo la transacción que lo ocupó puede liberar
Bifacility . La analogía más simple de
Bifacility puede considerarse una instalación tecnológica que realiza una serie de operaciones en una parte. Hasta que la parte abandone la instalación, es imposible enviarle otra parte.
Split - un componente diseñado para dividir una transacción en partes - otras transacciones procesadas en paralelo en el futuro. Por ejemplo, si consideramos una transacción como una orden, entonces sus partes son posiciones en la orden. Por defecto, en ausencia de cualquier parámetro,
Split divide la transacción resultante por una cantidad igual a los componentes posteriores. Es posible especificar cuántas partes y con qué modificador (para generar un valor aleatorio) se realizará la partición. Dado que en la práctica puede ser necesario que la división en partes se realice de acuerdo con alguna ley, en
Split es posible conectar su controlador para la división.
Emparejado con
Split es Aggregate , como su nombre lo indica, agrega una serie de transacciones en una. Su funcionalidad es bastante simple, después de haber recibido cualquiera de las partes de una transacción previamente interrumpida, espera todas las otras partes y, después de recibirlas, envía la transacción aún más.
Count - componente para contar. El constructor
Count cuenta con dos componentes: INC y DEC. Cuando una transacción ingresa a INC, el contador de
conteo aumenta; cuando ingresa a DEC, disminuye. En el constructor de
Count, los valores se establecen mediante los cuales el contador aumenta y disminuye cuando ingresa INC y DEC, respectivamente.
Asignar : diseñado para establecer algunos parámetros de transacción. Una transacción tiene una lista de parámetros, cada parámetro tiene un nombre y un valor. El valor puede ser una cadena, número, estructura. Al asignar nil a un parámetro, se elimina de la lista.
Verificar : un componente diseñado para verificar el cumplimiento de una determinada condición y omite una transacción solo cuando se ejecuta. Por defecto, se verifica la igualdad del parámetro de transacción con el valor especificado. En el constructor
Check , puede especificar el bloque al que se enviará la transacción si el resultado de la verificación es
falso . Para aumentar la flexibilidad, es posible conectar su propio controlador para verificar la condición de omisión de la transacción.
Vale la pena señalar que al desarrollar el marco, el objetivo no era copiar completamente GPSS, por lo tanto, con el nombre idéntico de los componentes, su funcionalidad puede variar.
Modelo de restaurante
La decisión de intentar construir un modelo de restaurante no surgió desde cero. En primer lugar, muchas personas los visitan, en segundo lugar, este es un sistema de colas bastante complicado, en tercer lugar, mi esposa ha estado trabajando en el negocio de los restaurantes durante muchos años, y podría consultar con ella.
Entonces, comenzaremos a describir el modelo del restaurante. El restaurante estará en 24 mesas. Los visitantes del restaurante se llaman "invitados", los invitados vienen al azar, se generarán transacciones. Pero la transacción no es una sola persona, puede ser un grupo de personas que solo tomaron una mesa. Para aumentar el realismo, si hay más de 6 invitados en la cola (se necesitan 6 mesas) esperando una mesa, los nuevos invitados se van, no esperan.
Las azafatas se encuentran con los invitados en la entrada, en los grandes restaurantes a menudo hay dos o más, habrá dos en el modelo. En caso de que haya mesas libres, las azafatas los llevan a la mesa, si no hay mesas libres, los invitados están esperando. En los restaurantes reales hay una reserva y los invitados VIP, por simplicidad, no estarán en el modelo construido, pero tales planes deben tenerse en cuenta.
Después de que los invitados se sientan en una mesa, son atendidos por un camarero, generalmente un camarero para varias mesas, en el modelo habrá uno para tres mesas. Como en un restaurante normal, el camarero no puede servir varias mesas a la vez, sino que las sirve de una en una. Durante el servicio, el camarero recibe un pedido de los invitados. Por orden se entiende varios platos de varios tipos y bebidas. No se sabe de antemano cuántos platos y bebidas se pedirán, pero contaremos al menos uno y no más de cinco, incluido el pedido en un bar. El camarero, una vez recibido el pedido, se lo pasa a los cocineros y camareros.
Tradicionalmente, entre los cocineros hay especializaciones: aperitivos y ensaladas, carnes, pasteles y postres, sushi. También habrá en el restaurante simulado: cuatro chefs que preparan diferentes platos. Habrá dos camareros.
Es una práctica común que no todos los platos traen de inmediato, sino tan pronto como estén listos. En consecuencia, los invitados no los comen todos a la vez, sino gradualmente. Y solo cuando comieron todos los platos puede pagar el pedido. Después de eso, la mesa puede ser desocupada.
Los parámetros de tiempo específicos se pueden ver en el
código .
Modelado
En la fig. 1 muestra el diagrama estructural del modelo. Para el modelado, casi todo el conjunto de componentes del marco está involucrado. Entonces, para estimar el número de invitados en la cola, se usa el componente
Verificar . Utilizando un controlador especializado, comprueba el número de invitados en la cola y, si se excede el número especificado, los envía a la salida.
Compruebe también si las tablas libres han aparecido.
Fig. 1. El diagrama estructural del modelo de restaurante.Con
Bifacility , puedes ocupar y liberar la mesa. Y
Asignar emparejado con
Verificar le permite especificar si el camarero transfiere el pedido de la mesa a la cocina o si ya entrega los platos terminados.
Como se puede ver en la fig. 1 cada uno de los chefs tiene una cola de pedidos, en realidad, por supuesto, es posible cocinar varios platos en paralelo, pero en el modelo presentado esto se omite. Para los camareros, la cola de pedidos es común.
Resultados de la simulación
Los resultados de la simulación se pueden encontrar
aquí . El informe muestra:
- no se utilizaron dos tablas (23 y 24) y, en general, una cuarta parte de las tablas prácticamente no se utilizan;
- el restaurante atendió a 29 visitantes y ninguno de los visitantes se fue sin entrar nunca al restaurante;
- los visitantes no tuvieron que esperar en la fila;
- al final de la simulación, 12 visitantes recibieron parte de su pedido y esperaban los platos restantes;
- los cocineros 1 y 4 tienen una carga muy grande (91.46%, 88.33%);
- Barman 2 no está cargado de trabajo (1.67%);
- la mitad de los camareros no están particularmente ocupados;
- la anfitriona 2 casi no está ocupada (9.38%).
En pocas palabras, el restaurante es grande y tiene mucho personal extra. O el restaurante está abierto en un lugar con poco tráfico (en el modelo presentado, los visitantes ingresan cada 10 ± 5 minutos). Si realiza la prueba con mayor tráfico (5 ± 3), la carga de personal aumenta significativamente, pero algunos de los visitantes se van sin esperar una mesa.
Conclusión
El modelo presentado, a pesar de una serie de simplificaciones, le permite simular bastante bien el restaurante y posiblemente incluso tiene un valor práctico. Pero los componentes, tanto nuevos como antiguos, ciertamente necesitan desarrollarse más. No todas las excepciones se manejan o manejan incorrectamente. Es necesario cubrir el código marco con pruebas y la documentación más importante. Todo esto está planeado y, en la medida de lo posible, se realizará.