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.