Contexte pour Décision Modèle et Notation

La norme Décision Modèle et Notation (DMN) a été créée en complément du Processus Métier Modèle et Notation (BPMN), utilisé principalement pour modéliser les diagrammes Processus Métier ; les deux normes ont été conçues pour fonctionner ensemble. BPMN a une activité spécialisée appelée Métier Rule Task , qui agit comme un espace réservé pour un calcul de règle métier à effectuer en fournissant des entrées et en attendant les sorties fournies par le moteur de règles. Cet élément sert de point de départ dans un modèle Décision , permettant ainsi de définir et de gérer des règles métier complexes et souvent volatiles séparément des modèles de processus.

La spécification Décision Modèle et Notation, cependant, indique clairement que le DMN peut être autonome, indépendamment du BPMN, et qu'il existe un certain nombre d'autres normes et langages qui peuvent être utilisés en conjonction avec le DMN. Cette liste identifie les langages qui - par conception ou par inférence - peuvent être utilisés en conjonction avec Décision Modèle et Notation ; les langages nouveaux et existants définiront à l'avenir des grammaires qui s'interfacent avec le DMN.

• Processus Métier Modèle et Notation
• Unified Modeling Language
• Langage Modélisation des Systèmes
• Modèle de gestion de cas et notation
• Archimate

Les décisions n'existent pas de manière isolée, ni ne sont-elles simplement la simplification de modèles de processus, mais elles sont plutôt l'expression d'une intention commerciale et forment souvent le tissu de ce qui différencie une organisation de ses concurrents. Le diagramme Décision Exigences permet à une organisation d'exprimer comment les décisions sont liées, et le diagramme Processus Métier articule à quels points d'un ensemble de processus elles sont invoquées. Enterprise Architect est positionné de manière unique en tant que plate-forme de modélisation d'entreprise pour montrer comment les décisions sont liées à d'autres contenus de modélisation d'entreprise, y compris comme décrit dans le reste de cette rubrique.

Processus Métier Modèle et Notation (BPMN)

Cette connexion entre les langages DMN et BPMN se traduira par des modèles de Processus Métier simplifiés et une séparation claire entre la description de ce que fait une organisation et les décisions qu'elle prend, permettant finalement à l'organisation de réagir rapidement et efficacement au changement.

Métier Règle Tâche

La tâche de règle Métier a été ajoutée dans les versions ultérieures de la spécification BPMN pour permettre à n'importe quel moteur Règles Métier d'être appelé à un point spécifié dans un Processus Métier , et pour que le moteur renvoie un résultat au processus une fois la demande traitée. C'est ce mécanisme qui peut être utilisé pour intégrer Décision Models avec Métier Processus , fournissant ainsi un mécanisme syntaxique pour séparer ces préoccupations assez différentes les unes des autres. Enterprise Architect est une plate-forme de modélisation riche, et elle permet non seulement de créer les deux types de modèles, mais aussi de les visualiser sur le même diagramme .

Ce diagramme générique montre comment ces modèles peuvent être visualisés dans l'outil ; la vue composite n'est qu'une option pour afficher les deux modèles, et dans cette vue, le modélisateur n'a inclus que la Décision de plus haut niveau et les deux Décisions contributives. Tous les détails du modèle Décision peuvent être consultés simplement en utilisant le menu contextuel Décisions et en sélectionnant « Rechercher | Retrouvez dans tous les Diagrammes '.

Langage Modélisation des Systèmes

Le Langage Modélisation des Systèmes (SysML) est largement utilisé par les ingénieurs système travaillant avec une méthodologie connue sous le nom d' Ingénierie Systèmes Modèles Basée (MBSE) pour décrire des systèmes complexes du monde réel. Il existe de nombreuses situations où les décisions font partie de la description de ces systèmes.

Cas d'utilisation

Le cas d'utilisation SysML peut être utilisé pour décrire un objectif qu'un utilisateur essaie d'atteindre en utilisant le système. Le cas d'utilisation peut être décrit à l'aide d'une série d'étapes créant généralement une interaction en amont et en aval entre l'utilisateur et le système. Les étapes que le système effectue nécessitent souvent des décisions à prendre et celles-ci peuvent être modélisées à l'aide d'un Modèle de Décision . Prenons un cas d'utilisation qui décrit un aspect du système de navigation d'un navire. Une étape dans un cas d'utilisation pourrait être "Le système décide du parcours optimal et des points de passage". Il y aurait généralement un certain nombre d'entrées dans cette décision qui pourraient être commodément enregistrées dans une Décision Modèle .

Activités et Actions

Le diagramme d'activité SysML est un cousin proche (mais plus ancien) du diagramme BPMN Processus Métier et utilise une notation et une sémantique similaires. Traditionnellement, la logique de décision est étroitement liée aux flux de processus utilisant les décisions, les fusions, les forks et les Jointures pour décrire les choix et les conditions dans lesquelles les décisions sont prises. Cela a conduit à des diagrammes de processus complexes et souvent peu maniables. À l'aide du DMN, les décisions (y compris leur logique) peuvent être supprimées du diagramme et placées dans un Modèle de Décision . Cela a pour effet de simplifier les diagrammes , ce qui se traduit par des flux de processus directs et un modèle où les décisions peuvent être raisonnées, facilement modifiées et également générées dans le code d'implémentation.

Unified Modeling Language

Le Unified Modeling Language ( UML ) est devenu la norme de facto pour la modélisation de systèmes centrés sur les entreprises et les logiciels. Les types de système qui sont modélisés à l'aide d' UML ont généralement des décisions importantes qui font partie de leur spécification et de leur mise en œuvre. Il existe un certain nombre d'endroits où la modélisation de la décision joue un rôle important.

Activités et Actions

Le diagramme d'activité UML est un cousin proche (mais plus ancien) du diagramme BPMN Processus Métier et utilise une notation et une sémantique similaires. Traditionnellement, la logique de décision est étroitement liée aux flux de processus utilisant les décisions, les fusions, les forks et les Jointures pour décrire les choix et les conditions dans lesquelles les décisions sont prises. Cela a conduit à des diagrammes de processus complexes et souvent peu maniables. À l'aide du DMN, les décisions (y compris leur logique) peuvent être supprimées du diagramme et placées dans un Modèle de Décision . Cela a pour effet de simplifier les diagrammes , ce qui se traduit par des flux de processus directs et un modèle où les décisions peuvent être raisonnées, facilement modifiées et également générées dans le code d'implémentation.

Use Cases et leurs cousins User Stories

Bien qu'il y ait souvent de vifs débats sur les différences entre les cas d'utilisation et les histoires d'utilisateurs, ils sont tous deux concernés par un objectif qu'un utilisateur essaie d'atteindre. Bon nombre de ces objectifs nécessitent que des décisions soient prises à différents stades du cas d'utilisation ou de la user story. Dans l'exemple des cas d'utilisation, un Modèle de Décision pourrait être utilisé pour décrire une étape du système dans le cas d'utilisation, telle que « Le système détermine le niveau d'accès à accorder à l'utilisateur ».

Composants

De nombreux systèmes sont divisés en une série de composants qui sont responsables d'une partie discrète de la fonction ou des services d'un système. Pour qu'un élément puisse mener à bien son travail, il est fréquemment appelé à prendre des décisions. Considérez un système de paie qui doit déterminer si les heures supplémentaires sont applicables dans une situation particulière, ou un système de contrôle du trafic aérien qui doit décider s'il faut mettre un avion entrant dans un circuit d'attente, et pour combien de temps. (La plupart des gens à un moment ou à un autre ont été les bénéficiaires de cette décision !)

Dispositifs

Qu'ils soient virtuels ou physiques, de nombreux appareils sont nécessaires pour prendre des décisions complexes. Considérez un routeur qui doit prendre des décisions complexes sur l'endroit où acheminer le trafic réseau, ou un contrôleur de trafic qui doit planifier divers mécanismes de contrôle du trafic pour optimiser le flux de trafic, ou un pare-feu qui protège le réseau d'une organisation.

Archimate

modélisation est un langage de modélisation d'architecture d'entreprise utilisé pour créer, gérer et visualiser des architectures à différents niveaux. Il existe un certain nombre d'endroits importants où les décisions peuvent être définies et décrites, y compris au niveau de la stratégie. Considérez une architecture qui définit un service d'application qui sélectionne un ensemble de produits par défaut à offrir à un client. La décision concernant les produits à regrouper pourrait être exprimée dans un modèle Décision .

Moteurs et objectifs

Les décisions peuvent être liées aux moteurs qui créent, motivent et alimentent le changement dans une organisation. Pour articuler pleinement les objectifs, les décisions peuvent être utilisées pour montrer les différences potentielles dans l'établissement de la direction. Il y a souvent des décisions de haut niveau qui doivent être prises à ce niveau d'une organisation.

Modèles d'informations d'entreprise

Les données d'entrée requises par les modèles Décision peuvent être liées à des entités dans des modèles d'information à n'importe quel niveau de détail, des modèles conceptuels de haut niveau aux schémas de modèles de données physiques. La connexion des modèles de Décision aux modèles d'information garantit que les données requises par la décision sont disponibles lorsqu'il s'agit de mettre en œuvre les décisions.

Politiques et procédures opérationnelles standard

Les décisions, les Métier de connaissances de métier ou les sources de connaissances peuvent être liés à des éléments qui modélisent des politiques, des procédures opérationnelles standard ou des flux de travail. Ceux-ci sont souvent la source d'information qui dicte ou guide les décisions.

Service d'application

Les décisions liées à la fourniture du service peuvent être liées aux services d'application pour montrer comment un service prend ses décisions.