Décision Modèle et Notation
Enterprise Architect 14

Enterprise Architect est prévu pour une sortie officielle au premier trimestre 2018.

DMN est seulement supporté dans Enterprise Architect 14

Non.

Oui. Le schéma de base de données d’Enterprise Architect est resté inchangé depuis Enterprise Architect 4.5.

Le processus de portage n’est pas requis. La structure du référentiel n’a pas été changée entre les versions.

Oui, la modélisation de DMN sera disponible dans l’édition Corporate. DMN Simulation et Execution sera disponible dans une édition supérieure. Plus d’informations sur des éditions et des fonctionnalités d’Enterprise Architect seront annoncées après la sortie officielle.

Il coûtera seulement si vous êtes à l’extérieur de votre période d’abonnement. Quand vous achetez Enterprise Architect, vous obtenez 12 mois d’avantages d’abonnement, y compris la possibilité de télécharger la dernière version d’Enterprise Architect.

Pour plus d’informations sur des avantages d’abonnement et la tarification de renouvellement, plaisez-vous référez à la page Informations de licence pour Enterprise Architect.

Oui, vous pouvez importer des fichiers XML DMN 1.1.
Use the Publier Ruban | Technologies | Importer | DMN 1.1

Oui. Utilisez le Publier Ruban | Importer XMI | Importer Model XMI... | Autres formats XML | DMN 1.1.

Une fois le fichier sélectionné, cliquez sur Importer bouton pour compléter le processus. Vous pouvez expérimenter avec la modélisation de DMN en important un fichier de Syntaxe DMN de la page Web DMN d’OMG.

Oui. Il existe plusieurs façons d’implémenter des conditions logiques. Par exemple, imaginez que nous voulons évaluer C = A XOR B.

1. Vous pouvez modéliser C comme une Table de décision: A et B sont 2 clauses d’entrée, alors que C est une clause de sortie.
2. Créez une fonction dans la bibliothèque DMN via le Code Ruban | Configurez | Options | Éditez le Gabarit de Code | DMN_JavaScript | DMNSim Bibliothèque:

   function XOR(a,b) {
return ( a || b ) && !( a && b );
}

3. Alors la Décision C peut être mise en œuvre comme une Expression Littérale: XOR(A, B)

DMN Expressions Supportées

• boxed literal expression
• boxed invocation
• boxed context
• Decision Table
• Function Definition
• List

DMN Expressions NON Supportées

• Relation (Comme tableau de base de données relationnelle)

Data types Supported:

• number
• string
• boolean

Type de données NON actuellement supporté

• time
• date
• date-time
• days and time duration
• years and month duration

Notez: si les expressions utilisant cette fois, la date, la durée et des types de date liés se conforment à la syntaxe de Javascript, Enterprise Architect pourra toujours le simuler. Autres exemples seront fournis à l’avenir.

Pour modélisation:

1. Une tâche de BPMN 2.0 se connectant à BPMN 2.0 DataObject liront les données, qui seront utilisées pour alimenter le Serveur DMN comme InputData.
2. Une variable de décision DMN peut être liée à la propriété d’un BPMN. En exécutant à BPMN 2.0 tâche de BusinessRule, le Serveur DMN sera invoquée et un résultat sera rendu.
3. La propriété peut alors être utilisée comme une condition de flux de séquence, sortante d’une passerelle.

Pour de simuler ensemble le BPMN et DMN, Enterprise Architect a fourni les fonctionnalités pour automatiser ce processus. Un webinaire sera prévu pour démontrer cette fonctionnalité bientôt.
Sont des règles de chaîne en avant et arrières supportées dans une Tableau de Décision?
Oui. Pour BusinessKnowledgeModel, vous pouvez vérifier/unité le test votre BKM en fournissant un ensemble de valeurs pour les paramètres et voir quelle règle(s) est activée. On ceci connaît comme en avant le raisonnement.

Vous pouvez aussi trier la sortie, donc l’utilisateur peut facilement répondre aux questions comme ceci: "si je veux que cette sortie spécifique soit activées, de quel type d’entrée ai-je besoin?" Ceci est connu comme un raisonnement vers l’arrière.

Non. Les données du demandeur peuvent être exportées et importées en utilisant la dialogue "Edit Data Set pour DMN Input data".

Les U et C + adhèrent à la politique d’activé pour ce tableau de décision particulière. La spécification DMN 1.1 stipule: "une table de décision a normalement plusieurs règles: par défaut, les règles ne se chevauchent pas. Si les règles se chevauchent, ce qui signifie que plus d’une règle peut correspondre à un ensemble donné de valeurs d’entrée, afin de reconnaître le type de tableau et de comprendre sans ambiguïté la logique de décision, la politique d’Activé peut être utilisée pour vérifier l’exactitude au moment de la conception.;

Ci-dessous est la description de la politique d’Activé pour les deux exemples démontrés dans le webinaire.

• U: Unique est une politique d’Activé seul: aucun chevauchement n’est possible et toutes les règles sont disjointes. Une seule règle peut être associée. Dans le webinaire, cela a été utilisé pour fournir un facteur de risque unique en ce qui concerne une demande de crédit.
• C +, une politique d’activation multiple: le résultat de la tableau de décision est la somme de toutes les sorties distinctes. Dans le webinaire ceci a été utilisé pour ajouter les valeurs pour calculer le score de crédit.

Vous pouvez générer du code à partir de Tableau de Décision et cela sera exploré plus en détail dans un webinaire à venir sur DMN.