Modelo conceptual
En la figura 2 se muestra un modelo de información conceptual de un sistema de estaciones de trabajo, en el que se definen dos tipos de objetos y cuatro tipos de eventos.
Figura 2: Modelo de información conceptual de los sistemas de estaciones de trabajo de fabricación.
Como expresan las asociaciones entre los cuatro tipos de eventos y los dos tipos de objetos, en los cuatro tipos de eventos participan los mismos dos tipos de objetos: piezas y puestos de trabajo, lo que implica que cada evento de estos cuatro tipos implica una pieza y un puesto de trabajo concretos.
Obsérvese que la memoria intermedia de entrada (llena de piezas en espera) se modela como un extremo de asociación con piezas en espera de nombre en el lado de las piezas de la asociación entre piezas y estaciones de trabajo, lo que expresa el hecho de que, en cualquier momento, una estación de trabajo tiene cero o más piezas en espera en su memoria intermedia de entrada para ser procesadas.
En la figura 3 se muestra un modelo de proceso conceptual de este sistema, que describe cuatro regularidades causales en forma de reglas de eventos, una para cada tipo de evento, en forma de diagrama de proceso BPMN que utiliza círculos de eventos conectados con flechas de flujo de secuencia que expresan la causalidad (condicional) y objetos de datos adjuntos a los círculos de eventos.
Figura 3: Modelo de proceso conceptual de un sistema de estación de trabajo de fabricación.
Las cuatro reglas de eventos descritas en el modelo de la figura 3 son las siguientes
- Cuando llega una pieza, se añade al búfer de entrada y, si la estación de trabajo está disponible, se producirá un evento de inicio de procesamiento para procesar la pieza recién llegada.
- Cuando se produce un evento de inicio de procesamiento, se está procesando la siguiente pieza de la memoria intermedia de entrada y se provoca un evento de fin de procesamiento para que se produzca algún tiempo después (una vez transcurrido el tiempo de procesamiento).
- Cuando se produce un evento de fin de procesamiento, esto provocará un evento de salida de parte y, si la memoria intermedia de entrada no está vacía, otro evento de inicio de procesamiento que implicará la siguiente parte de la memoria intermedia.
- Cuando se produce un evento de salida de pieza, la pieza procesada se retirará de la estación de trabajo.
Mientras que BPMN requiere categorizar todos los círculos de Evento en una de las tres categorías Evento de Inicio o Intermedio o Final y utilizar una sintaxis visual diferente para ellos, este no es el caso en DPMN.
Modelo de diseño
Un modelo de diseño de simulación se basa en un modelo conceptual. Dependiendo de los propósitos/objetivos de un estudio de simulación, puede abstraerse de ciertos elementos del dominio del mundo real descrito por el modelo conceptual, y añade elementos computacionales que representan decisiones de diseño, como variables aleatorias expresadas en forma de funciones de muestreo de variantes aleatorias basadas en distribuciones de probabilidad específicas para modelar la variación aleatoria de ciertas variables del sistema.
En la Figura 4 se muestra un modelo de diseño de la información del sistema de estación de trabajo única descrito anteriormente. Este modelo define el extremo de la asociación multivaluada waitingParts como ordenado, lo que significa que corresponde a una propiedad de referencia multivaluada que tiene como valor una colección ordenada (como una lista de matrices o una cola).
El modelo de diseño de información de la Figura 4 define que un evento PartArrival debe hacer referencia tanto a una Part como a una WorkStation, representando situaciones en las que partes específicas llegan a estaciones de trabajo específicas. Observe que, desde el punto de vista computacional, este modelo requiere crear nuevos objetos Pieza (o recuperarlos de una reserva de objetos) antes de crear (o programar) un nuevo evento LlegadaPieza, mientras que es más común en los modelos de simulación crear un nuevo objeto Pieza sólo cuando se ha producido un evento de llegada, lo que puede modelarse definiendo una multiplicidad de 0..1 para el extremo Pieza de la asociación LlegadaPieza-Pieza (con el significado de que LlegadaPieza tiene una propiedad de referencia opcional, en lugar de obligatoria, con nombre Pieza).
Figura 4: Modelo de diseño de información.
Observe que el modelo define dos operaciones a nivel de clase (designadas con el estereotipo "rv") que implementan funciones de muestreo de variantes aleatorias: PartArrival::recurrence() cumple con una distribución de probabilidad triangular con valores de parámetro mínimo, modo y máximo 3, 4 y 8, mientras queProcessingStart::processingTime() cumple con una distribución exponencial con un valor de parámetro de tasa de eventos de 6.
En la Figura 5 se muestra un modelo de diseño de procesos basado en los tipos de objetos y eventos definidos por el modelo de diseño de información de la Figura 4 y derivado del modelo conceptual de procesos de la Figura 3.
Figura 5: Modelo de diseño de procesos en forma de diagrama de procesos DPMN.
Nótese que, dado que todos los eventos ocurren en la misma estación de trabajo, las tres flechas de programación de eventos están anotadas con la misma asignación de propiedad de evento estación de trabajo := ws, que simplemente propaga la referencia de objeto a la estación de trabajo dada a lo largo de la cadena de programación de eventos. Tales asignaciones de propagación de propiedades (en anotaciones de asignación de propiedades de eventos), donde un valor de propiedad de un evento de seguimiento se establece en el correspondiente valor de propiedad del evento de programación (o desencadenante), se omitirán (como implica que los tipos de eventos tengan los mismos nombres de propiedades) para evitar saturar los diagramas del modelo de proceso.
Un Diagrama de Proceso DPMN, como el que se muestra en la Figura 5, puede dividirse en un conjunto de diagramas de reglas de eventos, uno para cada uno de sus círculos de Eventos, como se muestra en la Tabla 1. Esta reducción de un modelo de diseño de procesos DPMN a un conjunto de modelos de diseño de reglas de eventos, junto con la semántica operativa de las reglas de eventos presentada en (Wagner 2017), proporciona la semántica de los Diagramas de Procesos DPMN.
Tenga en cuenta que un modelo de diseño de reglas de eventos también se puede expresar textualmente en forma de un bloque de pseudocódigo con cuatro partes: la parte 1 indica el tipo de evento desencadenante y declara una variable de regla que representa el evento desencadenante, la parte 2 declara más variables de regla y las inicializa, la parte 3 contiene una secuencia de comandos de cambio de estado que consiste en declaraciones de cambio de estado, y la parte 4 programa eventos de seguimiento.
Tabla 1: Modelos de diseño de reglas de eventos.
ACTIVIDADES SIMPLES
Una actividad simple es una actividad con cero o más participantes, ninguno de los cuales tiene un significado especial (como ser un recurso o un objeto de procesamiento).
Modelado conceptual de actividades simples
Conceptualmente, una actividad es un evento compuesto enmarcado temporalmente por un par de eventos de inicio y fin. Por consiguiente, siempre que un modelo contenga un par de tipos de eventos de inicio y fin relacionados, como inicio de procesamiento y fin de procesamiento en el modelo de una estación de trabajo de fabricación que se muestra en la parte izquierda de la Figura 6 y la Figura 7, se pueden sustituir por un tipo de actividad correspondiente, como procesamiento, como se muestra en la parte derecha.
Figura 6: Introducción de una clase de actividad en un modelo conceptual de información.
Es evidente que la aplicación de este patrón de sustitución conduce a una simplificación conceptual y visual de los modelos en cuestión.
Figura 7: Introducción de una clase de actividad en un modelo conceptual de procesos.
Modelado de diseño de actividades sencillas
Al igual que en un modelo conceptual, también en un modelo de diseño, un par de tipos de evento de inicio y fin de actividad (o círculos de Evento), como ProcessingStart y ProcessingEnd en los modelos fuente mostrados en la Figura 8 y Figura 9, pueden ser reemplazados por un tipo de actividad correspondiente (o rectángulos de Actividad), como Processing, como en los modelos destino mostrados en estas figuras.
Figura 8: Ampliación de los modelos básicos de clase OEM a OEM-A mediante la introducción de tipos de actividad.
En el caso de un modelo de diseño de información, este patrón de sustitución implica asignar todas las características (atributos, asociaciones y operaciones) de las clases que definen el tipo de evento inicial y final en la clase que define el tipo de actividad correspondiente, posiblemente renombrando algunas de ellas. En el ejemplo de la Figura 7, sólo hay una característica de este tipo: la operación a nivel de clase ProcessingStart::processingTime, que se asigna a Processing y se renombra a time.
En el caso de un modelo de diseño de procesos, el patrón de reemplazo implica que un par de círculos de Eventos consistente en un círculo de Eventos destinado a representar un tipo de evento de inicio de actividad y un círculo de Eventos destinado a representar un tipo de evento de fin de actividad, con una flecha de programación de eventos desde el círculo de eventos de inicio de actividad al círculo de eventos de fin de actividad anotado por una expresión de retardo, es reemplazado por un rectángulo de Actividad tal que:
- Todos los Objetos de Datos adjuntos al círculo de evento de fin de actividad se adjuntan al rectángulo de Actividad (ya que una actividad ocurre cuando se completa).
- Todas las flechas de programación de eventos que salen del círculo de eventos de fin de actividad se convierten en flechas de programación de eventos que salen del rectángulo de Actividad.
- Todas las flechas de programación de eventos de inicio de actividad se sustituyen por flechas de programación de actividad correspondientes que tienen una asignación de parámetro de creación adicional para la duración de una actividad programada, que se establece en la expresión de retardo definida para la flecha de programación de eventos de fin de actividad. En el ejemplo anterior, Processing::time() en el diagrama de destino es el mismo que el retardo
- ProcessingStart::processingTime en el diagrama de origen.
- Cuando el círculo de evento de inicio de actividad tiene uno o más Objetos de Datos adjuntos o cualquier flecha de programación de eventos salientes que no va al círculo de evento de fin de actividad, entonces un círculo de evento de inicio de actividad tiene que ser incluido en el rectángulo de Actividad para adjuntar el(los) Objeto(s) de Datos y como la fuente de la(s) flecha(s) de programación de eventos salientes.
Figura 9: Extendiendo DPMN básico a modelos de proceso DPMN-A introduciendo rectángulos de Actividad.
Este Patrón de Reescritura Actividad-Inicio-Fin, que también puede ser aplicado en la dirección inversa, reemplazando un rectángulo de Actividad con un par de círculos de Evento, define el significado de un rectángulo de Actividad en un diagrama DPMN. Permite reducir un diagrama DPMN-A con rectángulos de Actividad a un diagrama DPMN básico sin rectángulos de Actividad.
Obsérvese que el modelo de destino de la Figura 9 especifica dos reglas de eventos:
- En cada llegada de pieza, si el estado de la estación de trabajo es AVAILABLE, entonces la variable de regla wsAllocated se establece en true y el atributo de estado de la estación de trabajo se establece en BUSY, de lo contrario la pieza llegada se añade a la memoria intermedia de entrada waitingParts de la estación de trabajo. Si la variable de regla wsAllocated tiene el valor true, se programa una nueva actividad de Procesamiento para que comience inmediatamente con sus atributos de duración (heredados) establecidos en el valor obtenido invocando la función de tiempo definida en la clase de actividad de Procesamiento.
- Cuando finaliza una actividad de Procesamiento, si la memoria intermedia de entrada waitingParts de la estación de trabajo está vacía, el atributo de estado de la estación de trabajo se establece en AVAILABLE, de lo contrario, la variable de regla wsReallocated se establece en true y la siguiente parte se elimina de la memoria intermedia de entrada waitingParts. Si la variable de reglawsReallocated tiene el valor true, se programa una nueva actividad de Procesamiento para que comience inmediatamente con su atributo de duración (heredado) establecido en el valor obtenido invocando la función de tiempo definida en la clase de actividad Procesamiento.
Observe que una estación de trabajo es un recurso exclusivo de su actividad de procesamiento. Los conceptos de recursos y de actividades con recursos limitados se tratan en las secciones siguientes.
ACTIVIDADES CON RECURSOS LIMITADOS
Una actividad con recursos limitados es una actividad en la que uno o más participantes desempeñan un rol de recurso (como el de ejecutante). Típicamente, una Actividad con Recursos Limitados es un componente de un proceso de negocio que ocurre en el contexto de una organización o unidad organizacional, la cual está asociada con la actividad como su Propietario de Proceso.
Una actividad de cierto tipo puede requerir ciertos recursos para poder ser realizada. En cualquier momento, un recurso necesario para realizar una actividad puede estar disponible o no.
Un recurso no está disponible, por ejemplo, cuando está ocupado o cuando está fuera de servicio. Los recursos son objetos de un tipo determinado. Mientras que en un modelo conceptual, que describe un sistema del mundo real, se requiere un ejecutor para cualquier actividad, un modelo de diseño de simulación puede prescindir del ejecutor de una actividad.
Por ejemplo, una actividad de consulta puede requerir un consultor y una sala. Estas restricciones de recursos se definen a nivel de tipo. Al definir el tipo de actividad Consulta, estas restricciones de recursos se definen en forma de dos asociaciones obligatorias con los tipos de objeto Consultor y Sala, de forma que los extremos de ambas asociaciones tengan la multiplicidad 1 ("exactamente uno"). Por lo tanto, en una simulación, sólo se puede iniciar una nueva actividad de consulta si se dispone de un objeto Consultor y un objeto Sala. Para todas las actividades con recursos limitados, un simulador puede recoger automáticamente las siguientes estadísticas:
Para cada tipo de actividad:
- la longitud de cola (media, máxima, etc.) de su cola de actividades planificadas;
- el tiempo de ciclo (medio, máximo, etc.), que es la suma del tiempo de espera y de la duración de la actividad;
- el porcentaje de tiempo que cada objeto de recurso implicado está ocupado con una actividad de ese tipo (su utilización por actividades de ese tipo).
El porcentaje de tiempo que cada objeto recurso está ocioso o fuera de servicio.
Para modelar las actividades con recursos limitados, necesitamos definir sus tipos. Un tipo de actividad con recursos limitados se compone de:
- un conjunto de propiedades y un conjunto de operaciones, como cualquier tipo de entidad
- un conjunto de roles de recursos, cada uno de los cuales tiene la forma de una propiedad de referencia con un nombre, un tipo de objeto como rango y una multiplicidad que puede definir una restricción de recursos como, por ejemplo, "se requiere exactamente un objeto de recursos de este tipo" o "se requieren al menos dos objetos de recursos de este tipo".
Los roles de recursos definidos para un tipo de actividad pueden incluir el rol de ejecutante. Un lenguaje de simulación para simular actividades debe permitir definir tipos de actividad con dos tipos de propiedades: propiedades ordinarias y roles de recursos. Al menos para estos últimos, debe ser posible definir multiplicidades para definir restricciones de recursos. Estos requisitos los cumplen los diagramas de clase OEM, en los que los roles de recursos se definen como propiedades estereotipadas mediante el estereotipo "rol de recurso" o, más abreviado, "res".
La extensión del OEM básico añadiendo los conceptos necesarios para modelar actividades con recursos limitados (en particular, roles de recursos con restricciones, pools de recursos y flechas de inicio de actividad dependientes de recursos) se denomina OEM-A.
Modelado conceptual de actividades con recursos limitados
El modelado de actividades con recursos limitados ha sido un tema importante en el campo de la Simulación de Eventos Discretos (DES) desde sus inicios en los años sesenta, mientras que se ha descuidado y todavía se considera un tema avanzado en el campo del Modelado de Procesos de Negocio (BPM). Por ejemplo, aunque BPMN permite asignar recursos a actividades, no permite modelar pools de recursos ni especificar restricciones de cardinalidad de recursos ni restricciones de multiplicidad de participación paralela.
En el paradigma DES de Redes de Procesamiento, Gordon (1961) ha introducido las operaciones de gestión de recursos Seize y Release en el lenguaje de simulación GPSS para asignar y desasignar (liberar) recursos. Así, GPSS ha establecido un patrón de modelado estándar para las actividades con recursos limitados, que se ha popularizado bajo el nombre de Seize-Delay-Release, que indica que para simular una actividad con recursos limitados, primero se asignan sus recursos y, después de un cierto retraso (que representa la duración de la actividad simulada), se desasignan (liberan).
Funciones de los recursos y propietarios de procesos
Como ejemplo ilustrativo, consideremos un hospital compuesto por departamentos médicos a los que llegan pacientes para que un médico les realice un reconocimiento médico en una sala del departamento. Un examen médico, como actividad, tiene cuatro participantes: un paciente, un departamento médico, un médico y una habitación, pero sólo dos de ellos desempeñan un papel de recurso: los médicos y las habitaciones. Esto puede indicarse en un diagrama de clases OEM utilizando el estereotipo "rol de recurso" para categorizar los extremos de asociación que representan roles de recurso, como se muestra en la Figura 10.
Obsérvese que tanto el tipo de evento llegadas de pacientes como el tipo de actividad exámenes tienen una propiedad de referencia (funcional obligatoria) propietario del proceso. Esto implica que tanto los eventos de llegada de pacientes como las actividades de examen ocurren en un departamento médico específico, que es su propietario de proceso en el sentido de que posee los tipos de proceso compuestos por ellos. Un propietario de proceso se llama "Participante" en BPMN (en el sentido de un participante de colaboración) y se representa visualmente en forma de un rectángulo contenedor llamado "Pool". En la Figura 10, el rol de recurso de los médicos se designa como el rol de ejecutante. También en BPMN, Performer se considera un tipo especial de rol de recurso. De acuerdo con la Sección 10.2.2 en la especificación BPMN 2.0 (BPMN 2011), un performer puede ser "un individuo específico, un grupo, un rol o posición de la organización, o una organización."
Una de las principales razones para considerar ciertos objetos como recursos es la necesidad de recopilar estadísticas de utilización (ya sea en un sistema de información operativo, como un sistema de gestión de flujos de trabajo, o en un modelo de simulación) registrando el uso de los recursos a lo largo del tiempo (su utilización) por tipo de actividad. Al designar roles de recursos en los modelos de información, estos modelos proporcionan la información necesaria en simulaciones y sistemas de información para recopilar automáticamente estadísticas de utilización.
Pools de recursos y asignación de recursos
En el ejemplo del hospital, un departamento médico, como propietario del proceso, es la unidad organizativa responsable de reaccionar ante determinados acontecimientos (en este caso, la llegada de pacientes) y de gestionar la realización de determinados procesos y actividades (en este caso, los reconocimientos médicos), incluida la asignación de recursos a estos procesos y actividades. Para poder asignar recursos a las actividades, el propietario de un proceso necesita gestionar pools de recursos, normalmente uno para cada rol de recursos de cada tipo de actividad (si los pools no se comparten entre roles de recursos). Un pool de recursos es una colección de objetos de recursos de un determinado tipo. Por ejemplo, las tres salas de rayos X de un departamento de diagnóstico por imagen forman un pool de recursos de ese departamento.
Las agrupaciones de recursos pueden modelarse en un diagrama de clases OEM mediante asociaciones especiales entre clases de objetos que representan propietarios de procesos (como departamentos médicos) y clases de recursos (como médicos y salas), donde los extremos de la asociación, correspondientes a propiedades con valores de colección que representan agrupaciones de recursos, se estereotipan con "agrupación de recursos", como se muestra en la figura 10. En cualquier momento, los objetos de recurso de una reserva de recursos pueden estar fuera de servicio (como una máquina defectuosa o un médico que no cumple su horario), ocupados o disponibles.
Figura 10: La clase de actividad "exámenes" con dos roles de recursos y dos pools de recursos.
El propietario de un proceso dispone de procedimientos especiales para asignar los recursos disponibles de los pools de recursos a las actividades. Por ejemplo, en el modelo de la figura 10, un departamento médico tiene los procedimientos "asignar un médico" y "asignar una sala" para asignar un médico y una sala a un examen médico. Estos procedimientos de asignación de recursos pueden utilizar diversas políticas, especialmente para asignar recursos humanos, como determinar primero la idoneidad de los recursos potenciales (por ejemplo, en función de los conocimientos, la experiencia y el rendimiento previo), clasificarlos y, por último, seleccionar entre los más adecuados (al azar o en función de su turno). Véase también (Arias et al 2018).
En el modelo de proceso conceptual que se muestra en la Figura 11, un médico y una sala siempre se asignan y liberan (desasignan) juntos.
Figura 11: Modelo de proceso conceptual basado en el modelo de información de la Figura 10.
Este modelo de proceso describe dos regularidades causales en forma de las dos reglas de eventos siguientes, cada una de ellas enunciada con dos viñetas: una para describir todos los cambios de estado y otra para describir todos los eventos de seguimiento provocados por la aplicación de la regla.
Cuando llega un nuevo paciente:
- si hay una habitación y un médico disponibles, se asignan al examen de ese paciente; de lo contrario, si no hay una habitación o un médico disponibles, el paciente se añade a la cola de espera;
- si se han asignado un médico y una sala, se inicia el reconocimiento del paciente.
Cuando un médico finaliza el reconocimiento en una sala determinada:
- si la fila de espera está vacía, se liberan la sala y el médico; de lo contrario, si todavía hay pacientes en la fila, se busca al siguiente paciente para que lo examine ese médico en esa sala;
- si se ha llamado a otro paciente, se inicia el examen de ese paciente.
Estas reglas de eventos conceptuales describen la dinámica real de un departamento médico en función de las decisiones de gestión del proceso de negocio. Los cambios en la línea de espera y la (des)asignación de salas y médicos se consideran cambios de estado (en el sistema de información, no necesariamente informatizado) del departamento, ya que se expresan en rectángulos de Objetos de Datos, que representan cambios de estado de los objetos afectados causados por un evento en DPMN.