Modelagem e simulação de processos de negócios com DPMN – Atividades com recursos limitados

Academic

O desafio

Este artigo tutorial, extraído de (Wagner 2019), mostra como usar Diagramas de Classe UML e Diagramas de Processo de Notação de Modelagem de Processos de Eventos Discretos (DPMN) para criar modelos de simulação de processos de negócios com atividades restritas a recursos com base no paradigma DES de Modelagem e Simulação de Eventos de Objetos. Nessa abordagem, a estrutura de estado de um sistema comercial é capturada por um diagrama UMLClass, que define os tipos de objetos, eventos e atividades subjacentes a um diagrama de processo DPMN, que captura as regularidades causais do sistema na forma de um conjunto de regras de eventos. Os diagramas de processo DPMN estendem os gráficos de eventos propostos por Schruben (1983), acrescentando elementos da BPMN (Business Process Modeling Notation), ou seja, objetos de dados e atividades e, como principal inovação em relação à BPMN, setas de início de atividade dependentes de recursos.

Introdução

A Modelagem e Simulação (M&S) de Eventos de Objeto (OE) é um novo paradigma geral de Simulação de Eventos Discretos (DES) proposto por Wagner (2018), que combina modelagem orientada a objetos e simulação baseada em eventos (com programação de eventos). O OEM&S baseia-se na ideia de que tanto os modelos conceituais de DES quanto os modelos de projeto de DES consistem em (1) um modelo de informações e (2) um modelo de processo. No caso da modelagem conceitual, um modelo de informações conceituais descreve os tipos de objetos e eventos que representam as principais entidades do sistema do mundo real sob investigação, enquanto um modelo de processo conceitual descreve sua dinâmica na forma de um conjunto de modelos de regras de eventos conceituais que capturam as regularidades causais do sistema.

No caso da modelagem de design de simulação, um modelo de design de informações prescreve (define) os tipos de todos os objetos e eventos que são relevantes para a finalidade de um estudo de simulação, definindo assim a estrutura de estado de um sistema DES, enquanto um modelo de design de processo define a dinâmica de um sistema DES definindo, para todos os tipos de eventos definidos pelo modelo de design de informações subjacente, um modelo de design de regra de evento que especifica as alterações de estado e os eventos de acompanhamento implícitos na ocorrência de um evento desse tipo.

Em (Wagner 2018), apresentamos uma variante da Notação de Modelagem de Processos de Negócios (BPMN), chamada Notação de Modelagem de Processos de Eventos Discretos (DPMN), e mostramos como usar Diagramas de Classe UML e Diagramas de Processo DPMN para criar modelos básicos de EO, definindo um conjunto de tipos de objetos OT, um conjunto de tipos de eventos ET e um conjunto de regras de eventos R. Em (Wagner 2017), mostramos que (a) esses três conjuntos definem um sistema de transição de estado, em que o espaço de estado é definido por OT e ET, e as transições são definidas por R, e (b) esse sistema de transição representa uma máquina de estado abstrata no sentido de Gurevich (1985). Essa caracterização fundamental de um modelo de OE fornece uma semântica formal (operacional) para a Simulação de OE (OES), definindo um formalismo de OES que qualquer simulador de OE precisa implementar.

Neste artigo tutorial, mostramos como estender o OEM/DPMN básico para adicionar suporte a atividades, resultando em uma extensão, OEM/DPMN-A, que compreende quatro novos elementos de modelagem de informações (Tipo de atividade, Função de recurso, Pool de recursos e Tipo de recurso) e dois novos elementos de modelagem de processos (Atividade e Seta de início de atividade dependente de recursos).

OEM&S BÁSICO

Considerações ontológicas

Ontologicamente, uma atividade é um evento composto (composto de pelo menos um evento de início e um evento de fim) com duração maior que zero, realizado por um agente (um ser humano ou outro ser vivo, um robô ou outro agente artificial, uma organização ou outro agente social).

Ao contrário das atividades, os eventos de início e fim de atividade são eventos instantâneos (duração zero). No mundo real, uma atividade tem pelo menos um participante: o executor da atividade. Consequentemente, um modelo conceitual deve, para cada tipo de atividade, incluir o tipo de objetos que desempenham a função de executor para atividades desse tipo.

No entanto, em um modelo de design de simulação, podemos deixar implícito o executor de uma atividade e modelar uma atividade sem modelar nenhum participante. Consequentemente, um simulador básico de EO, cujas classes principais estão descritas na Figura 1, não precisa suportar a distinção entre objetos e agentes.

Um processo discreto (instância) consiste em um conjunto parcialmente ordenado de eventos que ocorrem em uma região espaço-temporal atual determinada pelos participantes dos eventos e pelas regularidades causais envolvidas. Quando dois ou mais eventos em um processo têm a mesma classificação de ordem, isso significa que eles ocorrem simultaneamente.

Há muitos exemplos de processos discretos em vários domínios: (1) na biologia, a dinâmica da população de uma ou mais espécies que vivem em um determinado ecossistema (como o conhecido modelo predador-presa); (2) na sociologia, o processo de propagação de fofocas em uma comunidade; (3) na economia, um mercado baseado em ofertas e transações.

Um processo (instância) de negócios é um processo discreto que ocorre no contexto de uma organização. Normalmente, um processo de negócios é uma instância de um tipo de processo de negócios definido por uma organização (ou unidade organizacional), que é a proprietária do tipo de processo de negócios, na forma de um modelo de processo. Observe que esse conceito inclui processos de sistema de negócios, em que muitos agentes de negócios executam atividades para tratar de muitos casos de negócios em paralelo. Consequentemente, ele é mais geral do que o conceito comum de um processo de negócios como um processo de tratamento de casos, que prevalece no campo de Sistemas de Informação do Gerenciamento de Processos de Negócios.

Simulação de eventos de objeto

O paradigma da Simulação de Eventos de Objetos (OES) baseia-se na ideia de executar um modelo de OE a partir de um estado de simulação inicial, aplicando sucessivamente as regras de eventos do modelo aos estados de simulação em evolução. A Figura 1 mostra as principais classes de indivíduos com as quais um simulador de OE precisa lidar no tempo de execução.

Observe que o tempo de ocorrência de uma atividade é o tempo em que ela é concluída, ou seja, é igual aostartTime + duração. Normalmente, a duração de uma atividade em uma execução de simulação é conhecida e definida quando ela é iniciada. Um tipo de atividade é normalmente definido com uma duração fixa ou uma duração variável aleatória para todas as atividades desse tipo. Isso permite que um simulador programe o evento final da atividade quando ela é iniciada. Entretanto, em certos casos, um tipo de atividade pode não definir uma duração predefinida, mas deixar a duração das atividades desse tipo em aberto. Quando essa atividade ainda está em andamento, ela tem apenas uma hora de início, mas não tem duração nem hora de ocorrência.

Ilustrando os conceitos básicos de OEM com um exemplo

Como exemplo de OEM&S básico, apresentamos um modelo simples de OE de uma estação de trabalho de fabricação que recebe peças e as armazena em seu buffer de entrada para processá-las sucessivamente. Esse modelo consiste em (1) um modelo conceitual que descreve o domínio do mundo real e (2) um modelo de projeto de simulação que prescreve uma determinada solução computacional para fins de um estudo de simulação. Tanto os modelos conceituais quanto os modelos de projeto consistem em um modelo de informação que descreve/define a estrutura de estado do sistema e um modelo de processo que descreve/define a dinâmica do sistema. Um modelo de design de informações define os tipos de objetos e eventos como a base de um modelo de design de processo correspondente.

Figura 1: As principais classes de indivíduos com as quais um simulador de EO precisa lidar em tempo de execução.

A solução

Modelo conceitual

Um modelo de informações conceituais de um sistema de estação de trabalho, definindo dois tipos de objetos e quatro tipos de eventos, é mostrado na Figura 2.

Figura 2: Um modelo de informações conceituais de sistemas de estações de trabalho de manufatura.
Conforme expresso pelas associações entre os quatro tipos de eventos e os dois tipos de objetos, para todos os quatro tipos de eventos, há os mesmos dois tipos de objetos que participam deles: peças e estações de trabalho, o que implica que cada evento desses quatro tipos envolve uma peça específica e uma estação de trabalho específica.

Observe que o buffer de entrada (preenchido com peças em espera) é modelado como um final de associação com o nome de peças em espera no lado das peças da associação entre peças e estações de trabalho, expressando o fato de que, a qualquer momento, uma estação de trabalho tem zero ou mais peças em espera em seu buffer de entrada para serem processadas.

Um modelo de processo conceitual desse sistema, que descreve quatro regularidades causais na forma de regras de eventos, uma para cada tipo de evento, é mostrado na Figura 3 na forma de um diagrama de processo BPMN usando círculos de eventos conectados a setas de fluxo de sequência que expressam a causalidade (condicional) e objetos de dados anexados aos círculos de eventos.

Figura 3: Um modelo de processo conceitual de um sistema de estação de trabalho de manufatura.
As quatro regras de eventos descritas pelo modelo mostrado na Figura 3 são

Quando uma peça chega, ela é adicionada ao buffer de entrada e, se a estação de trabalho estiver disponível, haverá um evento de início de processamento para processar a peça recém-chegada.
Quando ocorre um evento de início de processamento, a próxima peça do buffer de entrada está sendo processada e um evento de fim de processamento é causado para ocorrer algum tempo depois (após o término do tempo de processamento).
Quando ocorrer um evento de fim de processamento, isso causará um evento de saída de peça e, se o buffer de entrada não estiver vazio, outro evento de início de processamento envolvendo a próxima peça do buffer.
Quando ocorrer um evento de saída de peça, a peça processada será removida da estação de trabalho.

Embora o BPMN exija a categorização de todos os círculos de eventos em uma das três categorias de evento inicial, intermediário ou final e o uso de uma sintaxe visual diferente para eles, esse não é o caso no DPMN.

Modelo de design

Um modelo de projeto de simulação é baseado em um modelo conceitual. Dependendo dos propósitos/objetivos de um estudo de simulação, ele pode abstrair certos elementos do domínio do mundo real descritos pelo modelo conceitual e adicionar elementos computacionais que representam as decisões de projeto, como variáveis aleatórias expressas na forma de funções de amostragem de variantes aleatórias baseadas em distribuições de probabilidade específicas para modelar a variação aleatória de determinadas variáveis do sistema.

Um modelo de design de informações do sistema de estação de trabalho única descrito acima é mostrado na Figura 4. Esse modelo define o fim da associação multivalorada waitingParts para ser ordenado, o que significa que ele corresponde a uma propriedade de referência multivalorada que contém uma coleção ordenada (como uma lista de matriz ou uma fila) como seu valor.

O modelo de design de informações da Figura 4 define que um evento PartArrival deve fazer referência tanto a uma peça quanto a uma estação de trabalho, representando situações em que peças específicas chegam a estações de trabalho específicas. Observe que, do ponto de vista computacional, esse modelo exige a criação de novos objetos Part (ou sua recuperação de um pool de objetos) antes que um novo evento PartArrival seja criado (ou programado), enquanto é mais comum em modelos de simulação criar um novo objeto Part somente quando ocorre um evento de chegada, que pode ser modelado pela definição de uma multiplicidade de 0...1 para a extremidade Part da associação PartArrival-Part (o que significa que Part Arrival tem uma propriedade de referência opcional, em vez de obrigatória, com o nome part).

Figura 4: Um modelo de design de informações.
Observe que o modelo define duas operações de nível de classe (designadas com o estereótipo "rv") que implementam funções de amostragem de variação aleatória: PartArrival::recurrence() está em conformidade com uma distribuição de probabilidade triangular com valores de parâmetro mínimo, modo e máximo 3, 4 e 8, enquantoProcessingStart::processingTime() está em conformidade com uma distribuição exponencial com um valor de parâmetro de taxa de eventos de 6.

Um modelo de projeto de processo baseado nos tipos de objetos e eventos definidos pelo modelo de projeto de informações da Figura 4 e derivado do modelo de processo conceitual da Figura 3 é mostrado na Figura 5.

Figura 5: Um modelo de projeto de processo na forma de um Diagrama de Processo DPMN.
Observe que, como todos os eventos ocorrem na mesma estação de trabalho, todas as três setas de programação de eventos são anotadas com a mesma atribuição de propriedade de evento workStation := ws, que simplesmente propaga a referência de objeto para a estação de trabalho determinada ao longo da cadeia de programação de eventos. Essas atribuições de propagação de propriedade (em anotações de atribuição de propriedade de evento), em que um valor de propriedade de um evento de acompanhamento é definido como o valor de propriedade correspondente do evento de agendamento (ou de acionamento), serão omitidas (conforme implícito pelos tipos de evento que têm os mesmos nomes de propriedade) para evitar a confusão nos diagramas do modelo de processo.

Um diagrama de processo DPMN, como o mostrado na Figura 5, pode ser dividido em um conjunto de diagramas de regras de eventos, um para cada um de seus círculos de eventos, conforme mostrado na Tabela 1. Essa redução de um modelo de design de processo da DPMN a um conjunto de modelos de design de regras de eventos, juntamente com a semântica operacional das regras de eventos apresentada em (Wagner 2017), fornece a semântica dos diagramas de processos da DPMN.

Observe que um modelo de design de regra de evento também pode ser expresso textualmente na forma de um bloco de pseudocódigo com quatro partes: a parte 1 indica o tipo de evento de acionamento e declara uma variável de regra que representa o evento de acionamento, a parte 2 declara outras variáveis de regra e as inicializa, a parte 3 contém um script de mudança de estado que consiste em instruções de mudança de estado e a parte 4 programa eventos de acompanhamento.

Tabela 1: Modelos de design de regras de eventos.

ATIVIDADES SIMPLES

Uma atividade simples é uma atividade com zero ou mais participantes, nenhum dos quais tem um significado especial (como ser um recurso ou um objeto de processamento).

Modelagem conceitual de atividades simples

Conceitualmente, uma atividade é um evento composto que é temporariamente enquadrado por um par de eventos de início e fim. Consequentemente, sempre que um modelo contiver um par de tipos de eventos de início e fim relacionados, como início e fim de processamento no modelo de uma estação de trabalho de manufatura mostrado no lado esquerdo da Figura 6 e da Figura 7, eles podem ser substituídos por um tipo de atividade correspondente, como processamento, conforme mostrado no lado direito.

Figura 6: Introdução de um tipo de atividade em um modelo de informação conceitual.
É óbvio que a aplicação desse padrão de substituição leva a uma simplificação conceitual e visual dos modelos em questão.

Figura 7: Introdução de um tipo de atividade em um modelo de processo conceitual.

Modelagem de projeto de atividades simples

Assim como em um modelo conceitual, também em um modelo de design, um par de tipos de eventos de início e fim de atividade correspondentes (ou círculos de eventos), como ProcessingStart e ProcessingEnd nos modelos de origem mostrados na Figura 8 e na Figura 9, pode ser substituído por um tipo de atividade correspondente (ou retângulos de atividade), como Processing, como nos modelos de destino mostrados nessas figuras.

Figura 8: Extensão do OEM básico para modelos de classe OEM-A com a introdução de tipos de atividade.
No caso de um modelo de design de informações, esse padrão de substituição implica a alocação de todos os recursos (atributos, associações e operações) das classes que definem o tipo de evento inicial e final na classe que define o tipo de atividade correspondente, possivelmente com a renomeação de alguns deles. No exemplo da Figura 7, há apenas um desses recursos: a operação em nível de classe ProcessingStart::processingTime, que é alocada para Processing e renomeada para time.

No caso de um modelo de design de processo, o padrão de substituição implica que um par de círculos de eventos que consiste em um círculo de eventos destinado a representar um tipo de evento de início de atividade e um círculo de eventos destinado a representar um tipo de evento de fim de atividade, com uma seta de programação de eventos do início da atividade para o círculo de eventos de fim de atividade anotado por uma expressão de atraso, é substituído por um retângulo de atividade de tal forma que:

Todos os objetos de dados anexados ao círculo de evento de fim de atividade são anexados ao retângulo de atividade (já que uma atividade ocorre quando é concluída).
Todas as setas de programação de eventos que saem do círculo de eventos de fim de atividade são transformadas em setas de programação de eventos que saem do retângulo Activity.
Todas as setas de agendamento de evento de início de atividade são substituídas por setas de agendamento de atividade correspondentes que têm uma atribuição de parâmetro de criação adicional para a duração de uma atividade agendada, que é definida como a expressão de atraso definida para a seta de agendamento de evento de fim de atividade. No exemplo acima, Processing::time() no diagrama de destino é o mesmo que o atraso
ProcessingStart::processingTime no diagrama de origem.
Quando o círculo de evento de início de atividade tiver um ou mais Objetos de Dados anexados ou qualquer seta de programação de eventos de saída que não vá para o círculo de evento de fim de atividade, um círculo de evento de início de atividade deverá ser incluído no retângulo de Atividade para anexar o(s) Objeto(s) de Dados e como a origem da(s) seta(s) de programação de eventos de saída.

Figura 9: Extensão da DPMN básica para modelos de processo da DPMN-A com a introdução de retângulos de atividade.

Esse padrão de reescrita atividade-início-fim, que também pode ser aplicado na direção inversa, substituindo um retângulo de atividade por um par de círculos de eventos, define o significado de um retângulo de atividade em um diagrama DPMN. Ele permite reduzir um diagrama DPMN-A com retângulos de atividade a um diagrama DPMN básico sem retângulos de atividade.

Observe que o modelo de destino da Figura 9 especifica duas regras de evento:

Na chegada de cada peça, se o status da estação de trabalho for AVAILABLE (disponível), a variável de regra wsAllocated (alocada) será definida como true (verdadeira) e o atributo de status da estação de trabalho será definido como BUSY (ocupado); caso contrário, a peça recebida será adicionada ao buffer de entrada da estação de trabalho waitingParts (peças em espera). Se a variável de regra wsAllocated tiver o valor true, uma nova atividade de processamento será programada para começar imediatamente com seus atributos de duração (herdados) definidos com o valor obtido pela invocação da função de tempo definida na classe de atividade de processamento.
Quando uma atividade de processamento termina, se o buffer de entrada waitingParts da estação de trabalho estiver vazio, o atributo de status da estação de trabalho será definido como AVAILABLE; caso contrário, a variável de regra wsReallocated será definida como true e a próxima peça será removida do buffer de entrada waitingParts. Se a variável de regrawsReallocated tiver o valor true, uma nova atividade de Processamento será programada para iniciar imediatamente com seu atributo de duração (herdado) definido como o valor obtido pela invocação da função de tempo definida na classe de atividade de Processamento.

Observe que uma estação de trabalho é um recurso exclusivo de sua atividade de processamento. Os conceitos de recursos e atividades com restrição de recursos são discutidos nas seções a seguir.

ATIVIDADES COM RESTRIÇÃO DE RECURSOS

Uma atividade com restrição de recursos é uma atividade em que um ou mais participantes desempenham uma função de recurso (como executor). Normalmente, uma Atividade com Restrição de Recursos é um componente de um processo de negócios que ocorre no contexto de uma organização ou unidade organizacional, que está associada à atividade como seu Proprietário do Processo.

Uma atividade de um determinado tipo pode exigir certos recursos para ser executável. Em qualquer momento, um recurso necessário para a execução de uma atividade pode estar disponível ou não.

Um recurso não está disponível, por exemplo, quando está ocupado ou quando está fora de serviço. Os objetos de recursos de uma atividade incluem seu executor. Embora em um modelo conceitual, que descreve um sistema do mundo real, seja necessário um executor para qualquer atividade, um modelo de design de simulação pode abstrair o executor de uma atividade.

Por exemplo, uma atividade de consulta pode exigir um consultor e uma sala. Essas restrições de recursos são definidas no nível do tipo. Ao definir o tipo de atividade Consulta, essas restrições de recursos são definidas na forma de duas associações obrigatórias com os tipos de objetos Consultor e Sala, de modo que as extremidades de ambas as associações tenham a multiplicidade 1 ("exatamente um"). Então, em uma execução de simulação, uma nova atividade de Consulta só pode ser iniciada quando um objeto Consultor e um objeto Sala estiverem disponíveis. Para todas as atividades com restrição de recursos, um simulador pode coletar automaticamente as seguintes estatísticas:

Para cada tipo de atividade:

o comprimento (médio, máximo, etc.) da fila de sua fila de atividades planejadas;
o tempo de ciclo (médio, máximo, etc.), que é a soma do tempo de espera e da duração da atividade;
a porcentagem de tempo em que cada objeto de recurso envolvido está ocupado com uma atividade desse tipo (sua utilização por atividades desse tipo).

A porcentagem de tempo em que cada objeto de recurso está ocioso ou fora de ordem.

Para modelar atividades com restrição de recursos, precisamos definir seus tipos. Um tipo de atividade com restrição de recursos é composto de:

um conjunto de propriedades e um conjunto de operações, como qualquer tipo de entidade
um conjunto de funções de recurso, cada uma com a forma de uma propriedade de referência com um nome, um tipo de objeto como intervalo e uma multiplicidade que pode definir uma restrição de recurso como, por exemplo, "exatamente um objeto de recurso desse tipo é necessário" ou "pelo menos dois objetos de recurso desse tipo são necessários".

As funções de recursos definidas para um tipo de atividade podem incluir a função de executor. Uma linguagem de simulação para simular atividades precisa permitir a definição de tipos de atividade com dois tipos de propriedades: propriedades comuns e funções de recursos. Pelo menos para essas últimas, deve ser possível definir multiplicidades para definir restrições de recursos. Esses requisitos são atendidos pelos Diagramas de Classe OEM, em que as funções de recursos são definidas como propriedades estereotipadas usando o estereótipo "função de recurso" ou, de forma mais curta, "res".

A extensão do OEM básico, acrescentando os conceitos necessários para modelar atividades com restrições de recursos (em particular, funções de recursos com restrições, pools de recursos e setas de início de atividades dependentes de recursos), é chamada de OEM-A.

Modelagem conceitual de atividades com restrição de recursos

A modelagem de atividades com restrições de recursos tem sido uma questão importante no campo da Simulação de Eventos Discretos (DES) desde seu início, na década de 1960, embora tenha sido negligenciada e ainda seja considerada um tópico avançado no campo da Modelagem de Processos de Negócios (BPM). Por exemplo, embora o BPMN permita atribuir recursos a atividades, ele não permite modelar pools de recursos e não permite especificar restrições de cardinalidade de recursos nem restrições de multiplicidade de participação paralela.

No paradigma DES de Redes de Processamento, Gordon (1961) introduziu as operações de gerenciamento de recursos Seize e Release na linguagem de simulação GPSS para alocar e desalocar (liberar) recursos. Assim, o GPSS estabeleceu um padrão de modelagem para atividades com restrição de recursos, que se tornou popular com o nome de Seize-Delay-Release, indicando que, para simular uma atividade com restrição de recursos, seus recursos são primeiro alocados e, depois de algum atraso (representando a duração da atividade simulada), são desalocados (liberados).

Funções de recursos e proprietários de processos

Como exemplo ilustrativo, consideramos um hospital composto por departamentos médicos em que os pacientes chegam para fazer um exame médico realizado por um médico em uma sala do departamento. Um exame médico, como uma atividade, tem quatro participantes: um paciente, um departamento médico, um médico e uma sala, mas apenas dois deles desempenham uma função de recurso: médicos e salas. Isso pode ser indicado em um diagrama de classes OEM usando o estereótipo "função de recurso" para categorizar as extremidades da associação que representam as funções de recurso, conforme mostrado na Figura 10.

Observe que tanto o tipo de evento "chegada de pacientes" quanto o tipo de atividade "exames" têm uma propriedade de referência (funcional obrigatória) "proprietário do processo". Isso implica que tanto os eventos de chegada de pacientes quanto as atividades de exames ocorrem em um departamento médico específico, que é o proprietário do processo, no sentido de que possui os tipos de processo compostos por eles. Um proprietário de processo é chamado de "Participante" no BPMN (no sentido de um participante de colaboração) e visualmente representado na forma de um retângulo de contêiner chamado "Pool". Na Figura 10, a função de recurso dos médicos é designada como função de executor. Também na BPMN, o executor é considerado um tipo especial de função de recurso. De acordo com a Seção 10.2.2 da especificação BPMN 2.0 (BPMN 2011), um executor pode ser "um indivíduo específico, um grupo, uma função ou posição organizacional ou uma organização".

Um dos principais motivos para considerar determinados objetos como recursos é a necessidade de coletar estatísticas de utilização (seja em um sistema de informações operacionais, como um sistema de gerenciamento de fluxo de trabalho, ou em um modelo de simulação) registrando o uso de recursos ao longo do tempo (sua utilização) por tipo de atividade. Ao designar funções de recursos em modelos de informações, esses modelos fornecem as informações necessárias em simulações e sistemas de informações para coletar automaticamente estatísticas de utilização.

Pools de recursos e alocação de recursos

No exemplo do hospital, um departamento médico, como proprietário do processo, é a unidade organizacional responsável por reagir a determinados eventos (aqui: chegada de pacientes) e gerenciar o desempenho de determinados processos e atividades (aqui: exames médicos), incluindo a alocação de recursos para esses processos e atividades. Para poder alocar recursos às atividades, o proprietário de um processo precisa gerenciar pools de recursos, normalmente um para cada função de recurso de cada tipo de atividade (se os pools não forem compartilhados entre as funções de recursos). Um pool de recursos é uma coleção de objetos de recursos de um determinado tipo. Por exemplo, as três salas de raios X de um departamento de diagnóstico por imagem formam um pool de recursos desse departamento.

Os pools de recursos podem ser modelados em um diagrama de classes OEM por meio de associações especiais entre classes de objetos que representam proprietários de processos (como departamentos médicos) e classes de recursos (como médicos e salas), em que as extremidades da associação, correspondentes às propriedades com valor de coleção que representam os pools de recursos, são estereotipadas com "pool de recursos", conforme mostrado na Figura 10. Em qualquer momento, os objetos de recursos de um pool de recursos podem estar fora de serviço (como uma máquina com defeito ou um médico que não está no horário), ocupados ou disponíveis.

Figura 10: O tipo de atividade "exames" com duas funções de recursos e dois pools de recursos.
Um proprietário de processo tem procedimentos especiais para alocar recursos disponíveis dos pools de recursos para as atividades. Por exemplo, no modelo da Figura 10, um departamento médico tem os procedimentos "alocar um médico" e "alocar uma sala" para alocar um médico e uma sala para um exame médico. Esses procedimentos de alocação de recursos podem usar várias políticas, especialmente para alocar recursos humanos, como primeiro determinar a adequação dos recursos em potencial (por exemplo, com base em conhecimento, experiência e desempenho anterior), depois classificá-los e, por fim, selecionar os mais adequados (aleatoriamente ou com base em sua vez). Consulte também (Arias et al 2018).

No modelo de processo conceitual mostrado na Figura 11, um médico e uma sala são sempre alocados e liberados (desalocados) juntos.

Figura 11: Um modelo de processo conceitual baseado no modelo de informações da Figura 10.
Esse modelo de processo descreve duas regularidades causais na forma das duas regras de eventos a seguir, cada uma declarada com dois pontos: um para descrever todas as alterações de estado e outro para descrever todos os eventos de acompanhamento provocados pela aplicação da regra.

Quando um novo paciente chega:

se uma sala e um médico estiverem disponíveis, eles serão alocados para o exame desse paciente; caso contrário, se uma sala ou um médico não estiverem disponíveis, o paciente será adicionado à fila de espera;
se um médico e uma sala tiverem sido alocados, iniciar o exame do paciente.

Quando um exame é concluído por um médico em uma determinada sala:

se a fila de espera estiver vazia, a sala e o médico serão liberados; caso contrário, se ainda houver pacientes na fila, o próximo paciente será chamado para ser examinado por esse médico nessa sala;
se outro paciente tiver sido chamado, o exame desse paciente será iniciado.

Essas regras de eventos conceituais descrevem a dinâmica do mundo real de um departamento médico de acordo com as decisões de gerenciamento de processos de negócios. As mudanças na fila de espera e as (des)alocações de salas e médicos são consideradas mudanças de estado (no sistema de informações, não necessariamente computadorizado) do departamento, pois são expressas em retângulos de objetos de dados, que representam mudanças de estado dos objetos afetados causadas por um evento na DPMN.

O impacto nos negócios

Enfileiramento de atividades planejadas

Sempre que uma atividade deve ser executada, mas não pode ser iniciada porque um recurso necessário não está disponível, a atividade planejada é colocada em uma fila como um trabalho em espera. Assim, no caso de um exame médico de um paciente, conforme descrito no modelo da Figura 10, a fila de espera representa, na verdade, uma fila de exames planejados (envolvendo pacientes), e não uma fila de pacientes em espera.

Como consequência dessas considerações, a fila de espera de um departamento médico modelado na Figura 10 como uma coleção ordenada de pacientes deve ser renomeada para caminhadas planejadas. Além disso, uma propriedade de exames planejados, que contém uma coleção ordenada de pares paciente-sala, deve ser adicionada à classe departamentos médicos. Esses elementos do modelo refletiriam a prática do processo de negócios do hospital de manter uma lista de pacientes aguardando a alocação de uma sala para caminhar e uma lista de exames planejados, cada um com um paciente aguardando um médico em uma sala de exames.

Exibição do proprietário do processo e dos executores da atividade

O proprietário do processo e os executores envolvidos podem ser exibidos em um diagrama de processo DPMN usando um contêiner Pool retangular para o proprietário do processo e partições Pool chamadas Lanes para os executores de atividade envolvidos, conforme mostrado na Figura 12.

Figura 12: Exibição do proprietário do processo e dos executores da atividade em um modelo de processo conceitual.

Atividades com restrição de recursos em modelos de projeto de simulaçãoAmpliação dediagramas de classe OEM com a adição de uma categoria de "tipo de recurso

O modelo de informações conceituais da Figura 10 contém dois tipos de objetos, salas e médicos, que são a gama de propriedades da função de recurso e do pool de recursos (fins de associação estereotipados "função de recurso" e "pool de recursos"). Esses tipos de objetos podem ser categorizados como "tipo de recurso" com o significado implícito de que herdam um atributo de status de recurso (com valores possíveis AVAILABLE, BUSY, OUT_OF_ORDER) e as operações de gerenciamento de recursos isAvailable, allocate e release de uma classe predefinida Resource. A introdução de tipos de recursos permite simplificar os modelos, eliminando esses itens de modelagem dos modelos de classe OEM-A, tornando-os parte de sua semântica implícita.

Ampliação dos diagramas de processo DPMN com a adição de setas de início de atividade dependentes de recursos

A desorganização dos diagramas de processo com a exibição de toda a lógica de gerenciamento de recursos exigida pelos tipos de atividade com restrição de recursos, conforme mostrado na Figura 12, pode ser evitada com a introdução do novo elemento de modelagem das setas de início de atividade dependente de recursos (RDAS), que combinam a programação de eventos com a fila de atividades planejadas que aguardam a disponibilidade de recursos. Por exemplo, na Figura 13, o significado intuitivo da seta RDAS entre o evento PatientArrival e a atividade WalkToRoom é: quando ocorrer um evento PatientArrival, inicie uma atividade WalkToRoom (para levar o paciente recém-chegado a uma sala de exames) assim que os recursos necessários (uma sala e uma enfermeira) estiverem disponíveis.Figura 13: Uso de setas de início de atividade dependente de recursos em um modelo de projeto de processo.

Observe que, ao contrário das ferramentas de modelagem "orientadas a processos" estabelecidas, como o AnyLogic, o modelo de processo DPMN da Figura 13 não precisa especificar nenhuma etapa de alocação/liberação de recursos, pois elas estão implícitas na especificação dos tipos de recursos e das restrições de cardinalidade de recursos dos tipos de atividade no modelo de classe OEM-A subjacente.

Anais da Conferência de Simulação de Inverno de 2020 K.-H. Bae, B. Feng, S. Kim, S. Lazarova-Molnar, Z. Zheng, T. Roeder e R. Thiesing, eds.

Gerd Wagner

Departamento de Informática
Universidade de Tecnologia de Brandemburgo
Konrad-Wachsmann-Allee 5
Cottbus, 03046, ALEMANHA

Referências

Arias, M., J. Munoz-Gama e M. Sepulveda. 2018. "Towards a Taxonomy of Human Resource Allocation Criteria" (Para uma taxonomia de critérios de alocação de recursos humanos). Em Business Process Management Workshops, editado por E. Teniente e M. Weidlich, 475-483, Heidelberg: Springer International Publishing.
Business Process Model and Notation (BPMN), Versão 2.0, 2011. http://www.omg.org/spec/BPMN/2.0, acessado em 13 de maio de 2020. Gordon, G. 1961. "Um programa de simulação de sistemas de propósito geral". Em AFIPS '61: Proceedings of the Eastern Joint Computer Conference, 87-104, Nova York: Association for Computing Machinery.
Gurevich, Y. 1985. "A New Thesis" [Uma nova tese]. Abstracts, American Mathematical Society, 6(4):317.
Schruben, L.W. 1983. "Simulation Modeling with Event Graphs". Communications of the ACM 26:957-963.
Wagner, G. 2019. "Modelagem de informações e processos para simulação - Parte II: atividades e redes de processamento".
https://dpmn.info/reading/Activities.html, acessado em 13 de maio de 2020.
Wagner, G. 2018. "Modelagem de informações e processos para simulação - Parte I: Objetos e eventos". Journal of Simulation Engineering 1:1-25. https://articles.jsime.org/1/1.
Wagner, G. 2017. "Uma semântica de máquina de estado abstrata para simulação de eventos discretos". Em Proceedings of the 2017 Winter Simulation Conference, editado por W. K. V. Chan, A.D'Ambrogio, G. Zacharewicz, N. Mustafee, G. Wainer e E. Page. 762-773. Piscataway, Nova Jersey: Institute of Electrical and Electronics Engineers, Inc.. https://www.informs- sim.org/wsc17papers/includes/files/056.pdf.

Biografia do autor

GERD WAGNER é Professor de Tecnologia da Internet no Departamento de Informática da Universidade de Tecnologia de Brandemburgo, Alemanha, e Professor Associado Adjunto no Departamento de Engenharia de Modelagem, Simulação e Visualização da Old Dominion University, Norfolk, VA, EUA. Seus interesses de pesquisa incluem modelagem e simulação, ontologias fundamentais, representação de conhecimento e engenharia da Web. Nos últimos anos, ele desenvolveu o paradigma OEM&S e a linguagem de modelagem de simulação de processos DPMN (consulte https://dpmn.info). Seu endereço de e-mail é G.Wagner@b-tu.de.

Back to Case Studies