Fil de navigation

Organisation de l'interrogation des Bases de Données des Règles et des Faits

La mise en place d'un logiciel d'enchères, qui doit interroger un grand nombre de base de données différentes, impose un séquencement approprié qui reproduise les étapes successives aux quelles les joueurs seront confrontées. C'est la spécification du séquenceur que je vous présente ci-dessous. Vous noterez que les Bases de Données sont personnalisés en fonctions de la situations des joueurs jusqu'au TOUR de PAROLE N°6 ..........ensuite jusqu'au contrat final il n'y plus que DEUX B.D, celle du camp de l'ouvreur et celle du camp de la défense qui utiliseront chacune des règles et finiront les enchères grâce au D.D.S pour établir les enchères restantes. On peut donc considérer que ces dernières enchères seront, comme pour tous les autres logiciels, totalement imprévisibles mais cohérentes vis à vis du contrat le plus réaliste !!!!!!!!

Voici les définitions des ETATS possibles des joueurs aux 4 premiers tours  de parole et la dénomination des B.D associées pour ces états :

Nouveauté Joomla 3.7: Un nouveau champ de type quelconque par article

Etat actuel de mes développements

 

Bien que je me sois intéressé en 2015,  pendant plusieurs mois, à une approche JAVA et à la structuration d'un projet basé sur les modèles de l'O.M.G SysML/UML2, j'ai continué à avancer dans la structuration de mes Bases de Données sous V.I.P. Je dispose donc actuellement d'un exécutable sous Windows qui génère des enchères sur  un premier tour de table et comporte :

1- la  BD complète des ouvertures en position 1 et 2 avec ses documents descriptifs des Règles implémentées (S.E.F plus P.SOULET).

2 - Les BD du répondant dans le Silence Adverse et Après Intervention avec les documents descriptifs des Règles implémentées.

3  - La BD des redemandes de L'ouvreur en position 1 et 2 dans le silence adverse avec les documents descriptifs des Règles implémentées.

4 - La BD du Défendeur, le répondant à l'intervenant.......... que le répondant à l'ouvreur Passe ou Enchérisse.

Je ne suis pas encore au bout de l'arbre compliqué qui doit aboutir à tous les cas de contrat, mais la "mécanique" du séquencement complet du logiciel est en place et toutes les BD qui seront impliquées dans les séquences suivantes sont  en place .......... mais encore "vides". La mise en place du séquencement et le passage  des règles formelles au profit de l'utilisation du D.D.S............ pour terminer les enchères a été long à choisir et à implémenter; il est actuellement fonctionnel la présentation des résultats reste sous une  forme de présentation technique utilisable pour continuer les tests des BD à venir.

Je peux fournir un exécutable de cet état du logiciel sur leur demande à ceux que cela intéresse à mon adresse : Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.

Nouveauté Joomla 3.7: Un nouveau champ de type quelconque par article

Méthodologie du projet

 

Méthodologie de Validation des Bases de Données

Le schéma ci-dessous explicite les étapes de validation des règles qui sont utilisées pour les choix de l'exécutable lors des ouvertures OU pour valider toutes les autres B.D de pour chaque séquence qui fait l'objet d'une BD particulière.

Le document initial explicite les règles utilisées sous les  formes littérales et  de "functors composés" du langage PROLOG.

Exemple : Modélisation des Enchères de Bridge_v1_DiffusionExterne_2013.docx

 

Nouveauté Joomla 3.7: Un nouveau champ de type quelconque par article

Clause logique de HORN

Le VIsual Prolog (VIP) et d’autres langages Prolog sont basés sur la Clause logique de HORN. Cette clause de HORN est un système formel pour raisonner sur des objets et sur la manière dont ces objets ont des relations entre eux.

Un exemple : Dans notre monde du Bridge on exprime en langage naturel une exigence comme celle-ci :

Un critère pour ouvrir au palier de un à la couleur est d’avoir une main avec 12 points d’honneurs.

Le premier travail du concepteur va consister à reformuler le plus simplement possible cette affirmation en :

  • Supprimant les mots inutiles qui n’ajoutent rien à l’information, check
  • Choisissant une organisation de la phrase en y  groupant les informations relatives à chaque objet, seek
  • Isolant le verbe qui indique la relation entre les objets
  • Remplaçant chaque objet par un mot mnémonique qui le caractérise au mieux.

Reprenons notre exemple et reformulons : Ouverture possible palier de un à la couleur avec 12 points d’honneur.

Nouveauté Joomla 3.7: Un nouveau champ de type quelconque par article

Utiliser un langage Procédural de type

Visual Basic ou un langage Déclaratif

comme Visual Prolog ?

 

Bien sur, malady tous ceux qui ont étudié ou développé dans des langages conventionnels et historiques comme Basic, patient Fortran, Pascal, C ou même à plus bas niveau en Assembleur ou directement en Code Machine, ne verront pas tout de suite l’intérêt du PROLOG et surtout l’évolution fondamentale de sa version moderne Orientée Objet le Visual Prolog 7.2 5 (V.I.P).

Ceux qui ont abordé des langages plus récents, tels que Ada, C++ et Visual Basic seront tout de suite convaincus de l’intérêt de l’orientation totalement objet de Visual Prolog 7.2 et de son I.D.E,l’atelier de développement « Visuel », qui est très proche des possibilités de Visual Studio pour les O.S  Windows de Microsoft.

Il reste à convaincre ces derniers, de l’intérêt d’un Langage Déclaratif Compilé qui sera appliqué aux enchères de Bridge et peut-être, plus tard, au jeu de la carte.

Eh bien, pour simplifier, la réponse tient en deux mots les Faits et les Règles, qui sont à la base d’un langage déclaratif, sont entièrement adaptés aux échanges d’informations des séquences d’enchères du bridge ; elles ont-elles aussi des caractéristiques FACTUELLES (des éléments déterministes) et des CONVENTIONS (les règles du système basées sur des statistiques), pour décrire les mains de Bridge entre  partenaires.

Nouveauté Joomla 3.7: Un nouveau champ de type quelconque par article