Simio Case Studies

Modélisation et simulation de processus d'entreprise avec DPMN - Activités à ressources limitées

Rédigé par Simio | 10 mars 2026 18:05:38

Le défi

Cet article, extrait de (Wagner 2019), montre comment utiliser les diagrammes de classes UML et les diagrammes de processus DPMN (Discrete Event Process Modeling Notation) pour créer des modèles de simulation de processus métier avec des activités à ressources limitées, sur la base du paradigme DES (Object Event Modeling and Simulation). Dans cette approche, la structure d'état d'un système commercial est capturée par un diagramme UMLClass, qui définit les types d'objets, d'événements et d'activités sous-jacents à un diagramme de processus DPMN, qui capture les régularités causales du système sous la forme d'un ensemble de règles d'événements. Les diagrammes de processus DPMN étendent les graphes d'événements proposés par Schruben (1983) en ajoutant des éléments de la notation BPMN (Business Process Modeling Notation), à savoir des objets de données et des activités, et, principale innovation par rapport à BPMN, des flèches de démarrage d'activité dépendant des ressources.

Introduction

La modélisation et la simulation objet-événement (OE) est un nouveau paradigme général de simulation d'événements discrets (DES) proposé par Wagner (2018), qui combine la modélisation orientée objet et la simulation basée sur les événements (avec ordonnancement des événements). OEM&S est basé sur l'idée que les modèles conceptuels pour DES et les modèles de conception DES consistent en (1) un modèle d'information et (2) un modèle de processus. Dans le cas de la modélisation conceptuelle, un modèle d'information conceptuel décrit les types d'objets et d'événements représentant les principales entités du système réel étudié, tandis qu'un modèle de processus conceptuel décrit sa dynamique sous la forme d'un ensemble de modèles de règles d'événements conceptuels qui capturent les régularités causales du système.

Dans le cas de la modélisation de la conception de la simulation, un modèle de conception de l'information prescrit (définit) les types de tous les objets et événements qui sont pertinents aux fins d'une étude de simulation, définissant ainsi la structure d'état d'un système DES, tandis qu'un modèle de conception de processus définit la dynamique d'un système DES en définissant, pour tous les types d'événements définis par le modèle de conception de l'information sous-jacent, un modèle de conception de règles d'événement qui spécifie les changements d'état et les événements de suivi impliqués par l'occurrence d'un événement de ce type.

Dans (Wagner 2018), nous avons présenté une variante de la notation BPMN (Business Process Modeling Notation), appelée notation DPMN (Discrete Event Process Modeling Notation), et nous avons montré comment utiliser les diagrammes de classes UML et les diagrammes de processus DPMN pour créer des modèles OE de base définissant un ensemble de types d'objets OT, un ensemble de types d'événements ET et un ensemble de règles d'événements R. Dans (Wagner 2017), nous avons montré que (a) ces trois ensembles définissent un système de transition d'état, où l'espace d'état est défini par OT et ET, et les transitions sont définies par R, et (b) un tel système de transition représente une machine d'état abstraite au sens de Gurevich(1985). Cette caractérisation fondamentale d'un modèle OE fournit une sémantique formelle (opérationnelle) pour la simulation OE (OES) en définissant un formalisme OES que tout simulateur OE doit mettre en œuvre.

Dans cet article, nous montrons comment étendre le modèle OEM/DPMN de base en y ajoutant un support pour les activités, ce qui donne une extension, OEM/DPMN-A, comprenant quatre nouveaux éléments de modélisation de l'information (Type d'activité, Rôle de ressource, Pool de ressources et Type de ressource) et deux nouveaux éléments de modélisation du processus (Flèche de démarrage de l'activité et de l'activité dépendante de la ressource).

OEM&S DE BASE

Considérations ontologiques

D'un point de vue ontologique, une activité est un événement composite (composé au moins d'un événement de début et d'un événement de fin) d'une durée supérieure à zéro, réalisé par un agent (un être humain ou un autre être vivant, un robot ou un autre agent artificiel, ou une organisation ou un autre agent social).

Contrairement aux activités, les événements de début et de fin d'activité sont des événements instantanés (durée nulle). Dans le monde réel, une activité a au moins un participant : l'exécutant de l'activité. Par conséquent, un modèle conceptuel devrait, pour chaque type d'activité, inclure le type d'objets qui jouent le rôle d'exécutant pour les activités de ce type.

Toutefois, dans un modèle de conception de simulation, nous pouvons laisser l'exécutant d'une activité implicite et modéliser une activité sans modéliser aucun participant. Par conséquent, un simulateur d'ENP de base, dont les classes principales sont décrites dans la figure 1, n'a pas besoin de faire la distinction entre les objets et les agents.

Un processus discret (instance) consiste en un ensemble partiellement ordonné d'événements qui se produisent dans une région spatio-temporelle déterminée par les participants aux événements et les régularités causales impliquées. Lorsque deux événements ou plus au sein d'un processus ont le même rang d'ordre, cela signifie qu'ils se produisent simultanément.

Il existe de nombreux exemples de processus discrets dans divers domaines : (1) en biologie, la dynamique de la population d'une ou plusieurs espèces vivant dans un certain écosystème (comme le modèle prédateur-proie bien connu) ; (2) en sociologie, le processus de propagation des ragots au sein d'une communauté ; (3) en économie, un marché basé sur des offres et des transactions.

Un processus métier (instance) est un processus discret qui se déroule dans le contexte d'une organisation. Typiquement, un processus métier est une instance d'un type de processus métier défini par une organisation (ou unité organisationnelle), qui est le propriétaire du type de processus métier, sous la forme d'un modèle de processus. Il convient de noter que ce concept englobe les processus des systèmes commerciaux, dans lesquels de nombreux acteurs commerciaux exécutent des activités pour traiter de nombreux cas commerciaux en parallèle. Par conséquent, il est plus général que le concept commun d'un processus commercial en tant que processus de traitement de cas, qui prévaut dans le domaine des systèmes d'information de la gestion des processus commerciaux.

Simulation d'événements d'objets

Le paradigme de la simulation d'événements par objets (OES) repose sur l'idée d'exécuter un modèle OE à partir d'un état de simulation initial en appliquant successivement les règles d'événements du modèle aux états de simulation évolutifs. La figure 1 illustre les principales classes d'individus qu'un simulateur OE doit gérer au moment de l'exécution.

Il convient de noter que le temps d'occurrence d'une activité est le moment où elle s'achève, c'est-à-dire qu'il est égal au temps de démarrage + la durée. En général, la durée d'une activité dans une simulation est connue et fixée au moment du démarrage. Un type d'activité est normalement défini avec une durée fixe ou une durée variable aléatoire pour toutes les activités de ce type. Cela permet au simulateur de programmer l'événement de fin de l'activité au moment du démarrage de l'activité. Toutefois, dans certains cas, un type d'activité peut ne pas définir de durée prédéfinie, mais laisser la durée des activités de ce type ouverte. Lorsqu'une telle activité est encore en cours, elle n'a qu'une heure de début, mais pas de durée ni d'heure d'occurrence.

Illustration des concepts de base des OEM à l'aide d'un exemple

Pour illustrer les concepts de base des OEM&S, nous présentons un modèle OE simple d'un poste de travail de fabrication qui reçoit des pièces et les stocke dans sa mémoire tampon d'entrée pour les traiter successivement. Un tel modèle se compose (1) d'un modèle conceptuel décrivant le domaine réel et (2) d'un modèle de conception de simulation prescrivant une certaine solution de calcul aux fins d'une étude de simulation. Les modèles conceptuels et les modèles de conception se composent d'un modèle d'information décrivant/définissant la structure d'état du système et d'un modèle de processus décrivant/définissant la dynamique du système. Un modèle de conception de l'information définit les types d'objets et d'événements comme base d'un modèle de conception de processus correspondant.

Figure 1 : Les principales classes d'individus qu'un simulateur d'ENP doit traiter au moment de l'exécution.

La solution

Modèle conceptuel

La figure 2 présente un modèle d'information conceptuel d'un système de postes de travail, définissant deux types d'objets et quatre types d'événements.

Figure 2 : Modèle d'information conceptuel des systèmes de postes de travail de fabrication.
Comme l'indiquent les associations entre les quatre types d'événements et les deux types d'objets, pour les quatre types d'événements, les deux mêmes types d'objets participent : les pièces et les postes de travail, ce qui implique que chaque événement de ces quatre types implique une pièce et un poste de travail spécifiques.

Notez que le tampon d'entrée (rempli de pièces en attente) est modélisé comme une fin d'association avec le nom des pièces en attente du côté des pièces de l'association entre les pièces et les postes de travail, exprimant le fait qu'à tout moment, un poste de travail a zéro pièce ou plus en attente dans son tampon d'entrée en vue d'être traitée.

Un modèle conceptuel de processus de ce système, décrivant quatre régularités causales sous la forme de règles d'événements, une pour chaque type d'événement, est présenté à la figure 3 sous la forme d'un diagramme de processus BPMN utilisant des cercles d'événements reliés à des flèches de flux de séquences exprimant la causalité (conditionnelle), et des objets de données attachés aux cercles d'événements.

Figure 3 : Modèle conceptuel de processus d'un système de postes de travail de fabrication.
Les quatre règles d'événement décrites par le modèle de la figure 3 sont les suivantes

  • Lorsqu'une pièce arrive, elle est ajoutée au tampon d'entrée et, si le poste de travail est disponible, il y aura un événement de début de traitement pour traiter la pièce nouvellement arrivée.
  • Lorsqu'un événement de début de traitement se produit, la pièce suivante de la mémoire tampon d'entrée est en cours de traitement et un événement de fin de traitement doit se produire un peu plus tard (après que le temps de traitement s'est écoulé).
  • Lorsqu'un événement de fin de traitement se produit, il entraîne un événement de départ de la pièce et, si la mémoire tampon d'entrée n'est pas vide, un autre événement de début de traitement impliquant la pièce suivante de la mémoire tampon.
  • Lorsqu'un événement de départ de pièce se produit, la pièce traitée est retirée du poste de travail.

Alors que BPMN exige de classer tous les cercles d'événements dans l'une des trois catégories Début, Intermédiaire ou Fin et d'utiliser une syntaxe visuelle différente pour eux, ce n'est pas le cas dans DPMN.

Modèle de conception

Un modèle de conception de simulation est basé sur un modèle conceptuel. En fonction des objectifs d'une étude de simulation, il peut s'abstraire de certains éléments du domaine réel décrit par le modèle conceptuel et ajouter des éléments de calcul représentant des décisions de conception, telles que des variables aléatoires exprimées sous la forme de fonctions d'échantillonnage de variables aléatoires basées sur des distributions de probabilités spécifiques pour modéliser la variation aléatoire de certaines variables du système.

Ce modèle définit l'association multivaluée waitingParts end comme étant ordonnée, ce qui signifie qu'elle correspond à une propriété de référence multivaluée ayant pour valeur une collection ordonnée (telle qu'une liste de tableaux ou une file d'attente).

Le modèle de conception de l'information de la figure 4 définit qu'un événement PartArrival doit faire référence à la fois à une pièce et à un poste de travail, représentant des situations où des pièces spécifiques arrivent à des postes de travail spécifiques. Notez que, sur le plan informatique, ce modèle nécessite la création de nouveaux objets Part (ou leur récupération à partir d'un pool d'objets) avant qu'un nouvel événement PartArrival ne soit créé (ou programmé), alors qu'il est plus courant dans les modèles de simulation de créer un nouvel objet Part uniquement lorsqu'un événement d'arrivée s'est produit, ce qui peut être modélisé en définissant une multiplicité de 0..1 pour l'extrémité Part de l'association PartArrival-Part (ce qui signifie que Part Arrival a une propriété de référence facultative, au lieu d'obligatoire, avec le nom Part).

Figure 4 : un modèle de conception de l'information.
Remarquez que le modèle définit deux opérations au niveau de la classe (désignées par le stéréotype "rv") mettant en œuvre des fonctions d'échantillonnage de variables aléatoires : PartArrival::recurrence() est conforme à une distribution de probabilité triangulaire avec des valeurs de paramètres minimum, mode et maximum de 3, 4 et 8, tandis queProcessingStart::processingTime() est conforme à une distribution exponentielle avec une valeur de paramètre de taux d'événement de 6.

La figure 5 présente un modèle de conception de processus basé sur les types d'objets et d'événements définis par le modèle de conception d'informations de la figure 4 et dérivé du modèle conceptuel de processus de la figure 3.

Figure 5 : modèle de conception de processus sous la forme d'un diagramme de processus DPMN.
Remarquez que, puisque tous les événements se produisent au même poste de travail, les trois flèches d'ordonnancement d'événements sont annotées avec la même affectation de propriété d'événement workStation := ws, qui propage simplement la référence d'objet au poste de travail donné le long de la chaîne d'ordonnancement d'événements. De telles affectations de propagation de propriété (dans les annotations d'affectation de propriété d'événement), où une valeur de propriété d'un événement de suivi est fixée à la valeur de propriété correspondante de l'événement d'ordonnancement (ou de déclenchement), seront omises (comme l'impliquent les types d'événements ayant les mêmes noms de propriété) pour éviter d'encombrer les diagrammes de modèle de processus.

Un diagramme de processus DPMN, tel que celui illustré à la figure 5, peut être divisé en un ensemble de diagrammes de règles d'événements, un pour chacun de ses cercles d'événements, comme le montre le tableau 1. Cette réduction d'un modèle de conception de processus DPMN en un ensemble de modèles de conception de règles d'événements, ainsi que la sémantique opérationnelle des règles d'événements présentée dans (Wagner 2017), fournit la sémantique des diagrammes de processus DPMN.

Notez qu'un modèle de conception de règles d'événement peut également être exprimé textuellement sous la forme d'un bloc de pseudo-code composé de quatre parties : la partie 1 indique le type d'événement déclencheur et déclare une variable de règle représentant l'événement déclencheur, la partie 2 déclare d'autres variables de règle et les initialise, la partie 3 contient un script de changement d'état composé d'instructions de changement d'état et la partie 4 planifie des événements de suivi.

Tableau 1 : Modèles de conception de règles d'événements.

ACTIVITÉS SIMPLES

Une activité simple est une activité avec zéro participant ou plus, dont aucun n'a de signification particulière (telle qu'être une ressource ou un objet de traitement).

Modélisation conceptuelle des activités simples

D'un point de vue conceptuel, une activité est un événement composite encadré temporellement par une paire d'événements de début et de fin. Par conséquent, chaque fois qu'un modèle contient une paire de types d'événements de début et de fin liés, comme le début et la fin du traitement dans le modèle d'un poste de travail de fabrication illustré dans la partie gauche des figures 6 et 7, ils peuvent être remplacés par un type d'activité correspondant, comme le traitement, tel qu'illustré dans la partie droite.

Figure 6 : introduction d'un type d'activité dans un modèle d'information conceptuelle.
Il est évident que l'application de ce schéma de remplacement conduit à une simplification conceptuelle et visuelle des modèles concernés.

Figure 7 : Introduction d'un type d'activité dans un modèle conceptuel de processus.

Modélisation de la conception d'activités simples

Comme dans un modèle conceptuel, dans un modèle de conception, une paire de types d'événements de début et de fin d'activité (ou cercles d'événements), comme ProcessingStart et ProcessingEnd dans les modèles sources illustrés aux figures 8 et 9, peut être remplacée par un type d'activité correspondant (ou rectangles d'activité), comme Processing, comme dans les modèles cibles illustrés dans ces figures.

Figure 8 : Extension des modèles de base OEM aux modèles de classe OEM-A par l'introduction de types d'activité.
Dans le cas d'un modèle de conception de l'information, ce schéma de remplacement implique l'attribution de toutes les caractéristiques (attributs, associations et opérations) des classes définissant le type d'événement de début et de fin dans la classe définissant le type d'activité correspondant, éventuellement en renommant certaines d'entre elles. Dans l'exemple de la figure 7, il n'y a qu'une seule caractéristique de ce type : l'opération au niveau de la classe ProcessingStart::processingTime, qui est attribuée à Processing et renommée en time.

Dans le cas d'un modèle de conception de processus, le modèle de remplacement implique qu'une paire de cercles d'événements consistant en un cercle d'événements destiné à représenter un type d'événement de début d'activité et un cercle d'événements destiné à représenter un type d'événement de fin d'activité, avec une flèche d'ordonnancement d'événements allant du cercle d'événements de début d'activité au cercle d'événements de fin d'activité annoté par une expression de délai, est remplacée par un rectangle d'activité tel que :

  • Tous les objets de données attachés au cercle de fin d'activité sont attachés au rectangle d'activité (puisqu'une activité se termine lorsqu'elle est achevée).
  • Toutes les flèches de programmation d'événements sortant du cercle de fin d'activité sont transformées en flèches de programmation d'événements sortant du rectangle d'activité.
  • Toutes les flèches de programmation d'événements de début d'activité sont remplacées par des flèches de programmation d'activités correspondantes ayant un paramètre de création supplémentaire pour la durée d'une activité programmée, qui est définie sur l'expression de délai définie pour la flèche de programmation d'événements de fin d'activité. Dans l'exemple ci-dessus, Processing::time() dans le diagramme cible est identique au délai
  • ProcessingStart::processingTime dans le diagramme source.
  • Lorsque le cercle d'événement de début d'activité comporte un ou plusieurs objets de données attachés ou une flèche d'ordonnancement d'événement sortant qui ne va pas vers le cercle d'événement de fin d'activité, un cercle d'événement de début d'activité doit être inclus dans le rectangle d'activité pour attacher le ou les objets de données et en tant que source de la ou des flèches d'ordonnancement d'événement sortant.

Figure 9 : Extension du DPMN de base aux modèles de processus DPMN-A par l'introduction de rectangles d'activité.

Ce schéma de réécriture Activité-Départ-Fin, qui peut également être appliqué dans le sens inverse, en remplaçant un rectangle d'activité par une paire de cercles d'événement, définit la signification d'un rectangle d'activité dans un diagramme DPMN. Il permet de réduire un diagramme DPMN-A avec des rectangles d'activité à un diagramme DPMN de base sans rectangles d'activité.

Remarquez que le modèle cible de la figure 9 spécifie deux règles d'événement :

  • A chaque arrivée de pièce, si le statut de la station de travail est AVAILABLE, la variable de règle wsAllocated prend la valeur true et l'attribut status de la station de travail prend la valeur BUSY, sinon la pièce arrivée est ajoutée au tampon d'entrée waitingParts de la station de travail. Si la variable de règle wsAllocated a la valeur true, une nouvelle activité de traitement est programmée pour démarrer immédiatement avec ses attributs de durée (hérités) fixés à la valeur obtenue en invoquant la fonction de temps définie dans la classe d'activité de traitement.
  • Lorsqu'une activité de traitement se termine, si le tampon d'entrée waitingParts de la station de travail est vide, l'attribut status de la station de travail prend la valeur AVAILABLE, sinon la variable de règle wsReallocated prend la valeur true et la pièce suivante est retirée du tampon d'entrée waitingParts. Si la variable de règle wsReallocated a la valeur true, une nouvelle activité de traitement est programmée pour démarrer immédiatement, son attribut de durée (hérité) étant défini sur la valeur obtenue en invoquant la fonction de temps définie dans la classe d'activité Traitement.

Notez qu'un poste de travail est une ressource exclusive de son activité de traitement. Les concepts de ressources et d'activités à ressources limitées sont abordés dans les sections suivantes.

ACTIVITÉS À RESSOURCES LIMITÉES

Une activité à ressources limitées est une activité dans laquelle un ou plusieurs participants jouent un rôle de ressource (tel qu'un exécutant). En règle générale, une activité à ressources limitées est un composant d'un processus métier qui se déroule dans le contexte d'une organisation ou d'une unité organisationnelle, qui est associée à l'activité en tant que propriétaire du processus.

Une activité d'un certain type peut nécessiter certaines ressources pour pouvoir être exécutée. À tout moment, une ressource nécessaire à l'exécution d'une activité peut être disponible ou non.

Une ressource n'est pas disponible, par exemple, lorsqu'elle est occupée ou lorsqu'elle est hors service. Les ressources sont des objets d'un certain type. Les objets ressources d'une activité comprennent son exécutant. Alors que dans un modèle conceptuel, décrivant un système réel, un exécutant est nécessaire pour toute activité, un modèle de simulation peut faire abstraction de l'exécutant d'une activité.

Par exemple, une activité de consultation peut nécessiter un consultant et une salle. Ces contraintes de ressources sont définies au niveau du type. Lors de la définition du type d'activité Consultation, ces contraintes de ressources sont définies sous la forme de deux associations obligatoires avec les types d'objets Consultant et Salle, de telle sorte que les extrémités des deux associations aient la multiplicité 1 ("exactement un"). Ainsi, lors d'une simulation, une nouvelle activité de consultation ne peut être lancée que si un objet Consultant et un objet Salle sont disponibles. Pour toutes les activités à ressources limitées, un simulateur peut automatiquement collecter les statistiques suivantes :

pour chaque type d'activité

  • la longueur (moyenne, maximale, etc.) de sa file d'attente d'activités planifiées ;
  • le temps de cycle (moyen, maximum, etc.), qui est la somme du temps d'attente et de la durée de l'activité ;
  • le pourcentage de temps pendant lequel chaque objet de ressource concerné est occupé par une activité de ce type (son utilisation par des activités de ce type).

Le pourcentage de temps pendant lequel chaque objet de ressource est inactif ou hors service.

Pour modéliser les activités à ressources limitées, nous devons définir leurs types. Un type d'activité sous contrainte de ressources est composé

  • d'un ensemble de propriétés et d'un ensemble d'opérations, comme tout type d'entité
  • d'un ensemble de rôles de ressources, chacun ayant la forme d'une propriété de référence avec un nom, un type d'objet comme plage, et une multiplicité qui peut définir une contrainte de ressource comme, par exemple, "exactement un objet de ressource de ce type est requis" ou "au moins deux objets de ressource de ce type sont requis".

Les rôles de ressources définis pour un type d'activité peuvent inclure le rôle de l'exécutant. Un langage de simulation d'activités doit permettre de définir des types d'activités avec deux types de propriétés : les propriétés ordinaires et les rôles de ressources. Au moins pour ces derniers, il doit être possible de définir des multiplicités pour définir les contraintes de ressources. Ces exigences sont satisfaites par les diagrammes de classes de l'OEM, dans lesquels les rôles de ressources sont définis comme des propriétés stéréotypées à l'aide du stéréotype "rôle de ressource" ou, plus brièvement, "res".

L'extension de l'OEM de base par l'ajout des concepts nécessaires à la modélisation des activités à ressources limitées (en particulier, les rôles de ressources avec contraintes, les pools de ressources et les flèches de démarrage d'activité dépendant des ressources) est appelée OEM-A.

Modélisation conceptuelle des activités à ressources limitées

La modélisation des activités à ressources limitées est un problème majeur dans le domaine de la simulation d'événements discrets (DES) depuis sa création dans les années soixante, alors qu'elle a été négligée et est toujours considérée comme un sujet avancé dans le domaine de la modélisation des processus d'entreprise (BPM). Par exemple, si le BPMN permet d'affecter des ressources aux activités, il ne permet pas de modéliser des pools de ressources, ni de spécifier des contraintes de cardinalité des ressources ou des contraintes de multiplicité des participations parallèles.

Dans le paradigme DES des réseaux de traitement, Gordon (1961) a introduit les opérations de gestion des ressources Seize et Release dans le langage de simulation GPSS pour l'allocation et la désallocation (libération) des ressources. Ainsi, le GPSS a établi un modèle de modélisation standard pour les activités à ressources limitées, qui est devenu populaire sous le nom de Seize-Delay-Release, indiquant que pour simuler une activité à ressources limitées, ses ressources sont d'abord allouées, puis, après un certain délai (représentant la durée de l'activité simulée), elles sont désallouées (libérées).

Rôles des ressources et propriétaires de processus

À titre d'exemple, nous considérons un hôpital composé de services médicaux où les patients arrivent pour subir un examen médical effectué par un médecin dans une salle du service. Un examen médical, en tant qu'activité, compte quatre participants : un patient, un service médical, un médecin et une salle, mais seuls deux d'entre eux jouent un rôle de ressource : les médecins et les salles. Ceci peut être indiqué dans un diagramme de classes OEM en utilisant le stéréotype "rôle de ressource" pour catégoriser les extrémités d'association qui représentent les rôles de ressource, comme le montre la figure 10.

Remarquez que le type d'événement "arrivée de patients" et le type d'activité "examens" ont tous deux une propriété de référence (fonctionnelle obligatoire) "propriétaire du processus". Cela implique que les événements d'arrivée de patients et les activités d'examen se produisent dans un service médical spécifique, qui est leur propriétaire de processus dans le sens où il possède les types de processus qui les composent. Un propriétaire de processus est appelé "Participant" en BPMN (dans le sens d'un participant à une collaboration) et représenté visuellement sous la forme d'un rectangle contenant appelé "Pool". Dans la figure 10, le rôle de ressource des médecins est désigné comme le rôle d'exécutant. Dans le BPMN également, l'exécutant est considéré comme un type spécial de rôle de ressource. Selon la section 10.2.2 de la spécification BPMN 2.0 (BPMN 2011), un exécutant peut être "un individu spécifique, un groupe, un rôle ou une position d'organisation, ou une organisation".

L'une des principales raisons de considérer certains objets comme des ressources est la nécessité de collecter des statistiques d'utilisation (soit dans un système d'information opérationnel, comme un système de gestion des flux de travail, soit dans un modèle de simulation) en enregistrant l'utilisation des ressources dans le temps (leur utilisation) par type d'activité. En désignant les rôles des ressources dans les modèles d'information, ces modèles fournissent les informations nécessaires aux simulations et aux systèmes d'information pour collecter automatiquement des statistiques d'utilisation.

Pools de ressources et allocation des ressources

Dans l'exemple de l'hôpital, un service médical, en tant que propriétaire du processus, est l'unité organisationnelle chargée de réagir à certains événements (ici : l'arrivée de patients) et de gérer l'exécution de certains processus et activités (ici : les examens médicaux), y compris l'allocation de ressources à ces processus et activités. Pour pouvoir allouer des ressources aux activités, un responsable de processus doit gérer des pools de ressources, normalement un pour chaque rôle de ressource de chaque type d'activité (si les pools ne sont pas partagés entre les rôles de ressources). Un pool de ressources est une collection d'objets de ressources d'un certain type. Par exemple, les trois salles de radiologie d'un service d'imagerie diagnostique constituent un pool de ressources de ce service.

Les pools de ressources peuvent être modélisés dans un diagramme de classes OEM au moyen d'associations spéciales entre les classes d'objets représentant les propriétaires de processus (comme les départements médicaux) et les classes de ressources (comme les médecins et les salles), où les extrémités de l'association, correspondant aux propriétés à valeur de collection représentant les pools de ressources, sont stéréotypées avec "pool de ressources", comme le montre la figure 10. À tout moment, les objets ressources d'un pool de ressources peuvent être en panne (comme une machine défectueuse ou un médecin qui n'est pas dans les temps), occupés ou disponibles.

Figure 10 : Le type d'activité "examens" avec deux rôles de ressources et deux pools de ressources.
Un responsable de processus dispose de procédures spéciales pour allouer les ressources disponibles des pools de ressources aux activités. Par exemple, dans le modèle de la figure 10, un service médical dispose des procédures "allouer un médecin" et "allouer une salle" pour allouer un médecin et une salle à un examen médical. Ces procédures d'affectation des ressources peuvent utiliser diverses politiques, en particulier pour l'affectation des ressources humaines, telles que la détermination de l'adéquation des ressources potentielles (par exemple, sur la base de l'expertise, de l'expérience et des performances antérieures), puis leur classement et enfin la sélection des ressources les plus adéquates (au hasard ou en fonction de leur tour de rôle). Voir également (Arias et al 2018).

Dans le modèle de processus conceptuel présenté à la figure 11, un médecin et une chambre sont toujours attribués et libérés (désattribués) ensemble.

Figure 11 : Modèle conceptuel de processus basé sur le modèle d'information de la figure 10.
Ce modèle de processus décrit deux régularités causales sous la forme des deux règles d'événement suivantes, chacune énoncée avec deux puces : une pour décrire tous les changements d'état et une pour décrire tous les événements de suivi provoqués par l'application de la règle.

Lorsqu'un nouveau patient arrive :

  • si une chambre et un médecin sont disponibles, ils sont affectés à l'examen de ce patient ; sinon, si une chambre ou un médecin n'est pas disponible, le patient est ajouté à la file d'attente ;
  • si un médecin et une chambre ont été attribués, l'examen du patient commence.

Lorsqu'un examen est terminé par un médecin dans une salle donnée :

  • si la file d'attente est vide, la salle et le médecin sont libérés ; sinon, s'il y a encore des patients dans la file d'attente, le patient suivant est appelé pour être examiné par ce médecin dans cette salle ;
  • si un autre patient a été appelé, l'examen de ce patient commence.

Ces règles conceptuelles décrivent la dynamique réelle d'un service médical en fonction des décisions de gestion des processus d'entreprise. Les modifications de la file d'attente et les (dé)attributions de chambres et de médecins sont considérées comme des changements d'état (dans le système d'information, pas nécessairement informatisé) du service, tels qu'ils sont exprimés dans les rectangles d'objets de données, qui représentent les changements d'état des objets concernés provoqués par un événement dans le DPMN.

L'impact sur l'entreprise

Mise en file d'attente des activités planifiées

Lorsqu'une activité doit être exécutée mais ne peut pas commencer en raison de l'indisponibilité d'une ressource requise, l'activité planifiée est placée dans une file d'attente en tant que travail en attente. Ainsi, dans le cas d'un examen médical d'un patient, tel que décrit dans le modèle de la figure 10, la file d'attente représente en fait une file d'examens planifiés (impliquant des patients), et non une file de patients en attente.

En conséquence de ces considérations, la ligne d'attente d'un service médical modélisé dans la figure 10 comme une collection ordonnée de patients doit être renommée en promenades planifiées. En outre, une propriété "examens planifiés", qui contient une collection ordonnée de paires de chambres de patients, devrait être ajoutée à la classe "services médicaux". Ces éléments de modèle refléteraient la pratique du processus métier de l'hôpital consistant à maintenir une liste de patients en attente de l'attribution d'une salle où se rendre et une liste d'examens planifiés, chacun avec un patient en attente d'un médecin dans une salle d'examen.

Affichage du responsable du processus et des exécutants de l'activité

Le propriétaire du processus et les exécutants impliqués peuvent être affichés dans un diagramme de processus DPMN en utilisant un conteneur Pool rectangulaire pour le propriétaire du processus et des partitions Pool appelées Lanes pour les exécutants de l'activité impliquée, comme le montre la figure 12.

Figure 12 : Affichage du propriétaire du processus et des exécutants de l'activité dans un modèle conceptuel de processus.

Activités à ressources limitées dans les modèles de conception par simulation - Extension desdiagrammes de classes OEM par l'ajout d'une catégorie "type de ressource

Le modèle d'information conceptuel de la figure 10 contient deux types d'objets, les chambres et les médecins, qui correspondent aux propriétés des rôles de ressources et des pools de ressources (l'association se termine par les stéréotypes "rôle de ressource" et "pool de ressources"). Ces types d'objets peuvent être classés dans la catégorie des "types de ressources", ce qui signifie implicitement qu'ils héritent d'un attribut d'état des ressources (avec les valeurs possibles DISPONIBLE, BUSY, OUT_OF_ORDER) et des opérations de gestion des ressources "isAvailable", "allocate" et "release" d'une classe prédéfinie "Resource". L'introduction de types de ressources permet de simplifier les modèles en supprimant ces éléments de modélisation des modèles de classe OEM-A et en les intégrant à leur sémantique implicite.

Extension des diagrammes de processus DPMN par l'ajout de flèches de début d'activité dépendant des ressources

L'encombrement des diagrammes de processus par l'affichage de toute la logique de gestion des ressources requise par les types d'activité à ressources limitées, comme le montre la figure 12, peut être évité en introduisant le nouvel élément de modélisation des flèches de démarrage d'activité dépendant des ressources (RDAS), qui combinent la programmation d'événements avec la mise en file d'attente d'activités planifiées attendant la disponibilité de ressources. Par exemple, dans la figure 13, la signification intuitive de la flèche RDAS entre l'événement PatientArrival et l'activité WalkToRoom est la suivante : lorsqu'un événement PatientArrival s'est produit, démarrer une activité WalkToRoom (pour accompagner le patient nouvellement arrivé jusqu'à une salle d'examen) dès que les ressources nécessaires (une salle et une infirmière) sont disponibles.Figure 13 : utilisation des flèches de début d'activité dépendante des ressources dans un modèle de conception de processus.

Notez que, contrairement aux outils de modélisation "orientés processus" établis, tels qu'AnyLogic, le modèle de processus DPMN de la figure 13 n'a pas besoin de spécifier d'étapes d'allocation/libération de ressources, puisqu'elles sont implicites en spécifiant les types de ressources et les contraintes de cardinalité des types d'activité dans le modèle de classe OEM-A sous-jacentPuisque les flèches de début d'activité dépendante des ressources de DPMN, comme le montre la figure 13, ne sont pas disponibles en BPMN, de nouveaux outils de modélisation devront être développés pour créer des diagrammes de processus DPMN.

Actes de la Conférence d'hiver sur la simulation 2020 K.-H. Bae, B. Feng, S. Kim, S. Lazarova-Molnar, Z. Zheng, T. Roeder, et R. Thiesing, eds.

Gerd Wagner

Département d'informatique
Université de technologie de Brandebourg
Konrad-Wachsmann-Allee 5
Cottbus, 03046, ALLEMAGNE

Références

Arias, M., J. Munoz-Gama et M. Sepulveda. 2018. "Vers une taxonomie des critères d'allocation des ressources humaines". Dans Business Process Management Workshops, édité par E. Teniente et M. Weidlich, 475-483, Heidelberg : Springer International Publishing.
Business Process Model and Notation (BPMN), Version 2.0, 2011. http://www.omg.org/spec/BPMN/2.0, consulté le 13 mai 2020. Gordon, G. 1961. "A general purpose systems simulation program". Dans AFIPS '61 : Proceedings of the Eastern Joint Computer Conference, 87-104, New York : Association for Computing Machinery.
Gurevich, Y. 1985. "A New Thesis". 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. "Information and Process Modeling for Simulation - Part II : Activities and Processing Networks".
https://dpmn.info/reading/Activities.html, consulté le 13 mai 2020.
Wagner, G. 2018. "Information and Process Modeling for Simulation - Part I : Objects and Events" (Modélisation de l'information et des processus pour la simulation - Partie I : Objets et événements). Journal of Simulation Engineering 1:1-25. https://articles.jsime.org/1/1.
Wagner, G. 2017. "An Abstract State Machine Semantics for Discrete Event Simulation". In Proceedings of the 2017 Winter Simulation Conference, édité par W. K. V. Chan, A.D'Ambrogio, G. Zacharewicz, N. Mustafee, G. Wainer, et E. Page. 762-773. Piscataway, New Jersey : Institute of Electrical and Electronics Engineers, Inc. https://www.informs- sim.org/wsc17papers/includes/files/056.pdf.

Biographie de l'auteur

GERD WAGNER est professeur de technologie Internet au département d'informatique de l'université technologique de Brandebourg, en Allemagne, et professeur associé au département de modélisation, de simulation et d'ingénierie de la visualisation de l'université Old Dominion, à Norfolk, en Virginie, aux États-Unis. Ses recherches portent sur la modélisation et la simulation, les ontologies fondamentales, la représentation des connaissances et l'ingénierie web. Ces dernières années, il a développé le paradigme OEM&S et le langage de modélisation de simulation de processus DPMN (voir https://dpmn.info). Son adresse électronique est G.Wagner@b-tu.de.
Voir l'article complet