Contexte du Decision Model and Notation

La norme Decision Model and Notation (DMN) a été créée pour compléter la Business Process Model and Notation (BPMN) , utilisée principalement pour modéliser diagrammes Processus Métier ; les deux normes ont été conçues pour fonctionner ensemble. BPMN possède 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 agit comme le point de départ d'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 Decision Model and Notation précise toutefois que le DMN peut être autonome, indépendamment de BPMN, et qu'il existe un certain nombre d'autres normes et langages qui peuvent être utilisés conjointement avec le DMN. Cette liste identifie les langages qui, de par leur conception ou par déduction, peuvent être utilisés conjointement avec le Decision Model and Notation ; les langages nouveaux et existants définiront à l'avenir des grammaires qui s'interfacent avec le DMN.

• Business Process Model and Notation
• Unified Modeling Language
• Langage Modélisation des Systèmes
• Case Management Model and Notation
• ArchiMate

Les décisions n'existent pas de manière isolée et ne sont pas non plus une simple simplification de modèles de processus. Elles sont plutôt l'expression d'une intention commerciale et constituent souvent la trame de ce qui différencie une organisation de ses concurrents. Le diagramme Décision Exigences permet à une organisation d'exprimer la manière dont 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 particulièrement bien placé en tant que plate-forme modélisation d'entreprise pour montrer comment les décisions sont liées à d'autres contenus modélisation d'entreprise, notamment comme décrit dans le reste de cette rubrique.

Business Process Model and Notation (BPMN)

Cette connexion entre les langages DMN et BPMN donnera lieu à des modèles 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 in fine à l’organisation de réagir rapidement et efficacement au changement.

Tâche de règle Métier

La tâche Métier Rule a été ajoutée dans les versions ultérieures de la spécification BPMN pour permettre à tout 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 requête 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 très différentes les unes des autres. Enterprise Architect est une plate-forme modélisation riche, et elle permet non seulement de créer les deux types de modèles, mais également 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 niveau le plus élevé et les deux Décisions contributives. Les détails complets du modèle Décision peuvent être visualisés en utilisant simplement le menu contextuel Décisions et en sélectionnant « Rechercher | Rechercher dans tous Diagrammes ».

Langage Modélisation des Systèmes

Le Systems Modeling Language (SysML) est largement utilisé par les ingénieurs systèmes 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 dans lesquelles 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 tente 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 exécute nécessitent souvent de prendre des décisions et celles-ci peuvent être modélisées à l'aide d'un Modèle 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 cap optimal et des points de cheminement ». Il y aurait généralement un certain nombre d'entrées dans cette décision qui pourraient être facilement enregistrées dans un Modèle Décision .

Activités et actions

Le diagramme d'activité SysML est un proche (mais plus ancien) cousin du diagramme Processus Métier BPMN et utilise une notation et une sémantique similaires. Traditionnellement, la logique de décision a été étroitement liée aux flux de processus en utilisant des décisions, des fusions, des fourches et Jointures pour décrire les choix et les conditions dans lesquelles les décisions sont prises. Cela a conduit à diagrammes de processus complexes et souvent peu maniables. En utilisant le DMN, les décisions (y compris leur logique) peuvent être supprimées du diagramme et placées dans un Modèle Décision . Cela a pour effet de simplifier les diagrammes , ce qui donne lieu à des flux de processus directs et à un modèle dans lequel 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 modélisation des systèmes métier et logiciels. Les types de systèmes modélisés à l'aide UML comportent 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 de domaines dans lesquels modélisation des décisions joue un rôle important.

Activités et actions

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

Cas d'utilisation et leurs cousins User Stories

Bien qu'il existe souvent des débats animés sur les différences entre les cas d'utilisation et les récits d'utilisateur, ils concernent tous deux un objectif qu'un utilisateur tente d'atteindre. Bon nombre de ces objectifs nécessitent des décisions à prendre à différents moments du cas d'utilisation ou du récit d'utilisateur. Dans l'exemple des cas d'utilisation, un Modèle Décision pourrait être utilisé pour décrire une étape du système dans le cas d'utilisation, par exemple « 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 distincte de la fonction ou des services d'un système. Pour qu'un composant puisse effectuer son travail, il doit souvent prendre des décisions. Prenons l'exemple d'un système de paie qui doit déterminer si les heures supplémentaires sont applicables dans une situation particulière, ou d'un système de contrôle du trafic aérien qui doit décider s'il faut placer un avion entrant en motif attente et pour combien de temps. (La plupart des gens ont dû, à un moment ou à un autre, prendre cette décision !)

Appareils

Qu'ils soient virtuels ou physiques, de nombreux appareils doivent prendre des décisions complexes. Prenons l'exemple d'un routeur qui doit prendre des décisions complexes sur l'acheminement du trafic réseau, d'un contrôleur de trafic qui doit planifier divers mécanismes de contrôle du trafic pour optimiser le flux de trafic, ou encore d'un pare-feu qui protège le réseau d'une organisation.

ArchiMate

ArchiMate est un langage modélisation 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, notamment 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 à proposer à un client. La décision concernant les produits à regrouper pourrait être exprimée dans un modèle Décision .

Pilotes et objectifs

Les décisions peuvent être liées aux facteurs 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 la définition 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'information d'entreprise

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

Politiques et procédures opérationnelles normalisées

Les décisions, les modèles de connaissances Métier ou les sources de connaissances peuvent être liés à des éléments qui modélisent des politiques, des procédures opérationnelles normalisées ou des flux de travail. Ceux-ci sont souvent la source d'informations qui dictent ou guident les décisions.

Service d'application

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