Fil de navigation

Formalisme des Implémentations des classes en Java et en VIP

Avant de reconstituer des diagrammes de classes pour mon logiciel, en visant Java comme langage d'implémentation finale, nous allons établir une première approche de comparaison entre V.I.P et Java concernant  l’implémentation des classes dans ces deux langages.

Dans les deux langages une classe est constituée par un CLASSEUR (un Dossier) qui contiendra l'arborescence des fichiers de la classe.

Prenons un exemple pour JAVA extrait d’un tutorial pour UNE CLASSE Nommée Point

 

En java : Une CLASSE  est située dans une arborescence d’un répertoire projet (ProjetJava)  comportant un sous répertoire des classes du Projet ( src)  et elle est représentée par un seul Fichier source d’extension « java » (classeJava.java) qui sera compilé, par le compilateur JAVAC, pour produire un fichier en  « byte code » d’extension « class » (classeJava.class). Seule la machine virtuelle (JavaM) sera capable d’interpréter sous l’Operating System sur lequel la JavaM et le fic hier byte code de la classe seront installés.

Pour VIP nous prenons ici les définitions du livre de référence du langage (malheureusement en Anglais seulement!)


 

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

Comparaison de l'Etude de la classe "Mainbridge" de VIP qui a servi à générer des objets dans mon logiciel, et une modélisation UML similaire en 2016

A plusieurs occasions lors de mes travaux de ces 5 dernières années,  j'ai constaté que dans l'avancement de mon logiciel « bridgrexpertia » je n’avais que très peu utilisé des objets instanciés à partir d’une classe, malgré un contexte de développement de nombreuses classes indispensables à ce logiciel. Je pense qu’aujourd’hui je pourrais choisir une approche conceptuelle bien plus orientée objet même en restant sous VIP. Avant d’aller plus loin dans ce sens je me propose de reprendre la classe des quatre mains d’une donne en reprenant une modélisation de l’existant, appuyée sur UML dans l’IDE Eclipse avec le Plugin gratuit PAPYRUS.

Mes choix de modélisation au départ du projet:

 

La Figure ci-dessus représente le modèle des classes de base de mon logiciel, lors de mon étude de Faisabilité, lorsqu’il permettait de proposer uniquement les Ouvertures en premier. Je reprends son  étude ici, dans ma nouvelle démarche de réflexion, car elle était relativement simple pou cette étape initiale du développement. La représentation des classes était basée sur le formalisme des années 2000 de GRADY BOOCH, un des « pères » de UML. Avec le formalisme du langage UML on se trouve en présence d’un diagramme de clase de haut niveau qui représente au départ des classes ABSTRAITES, c.à.d sans la description de tous leurs attributs et de leurs fonctions qui seront optionnellement ajoutés ultérieurement dans des diagrammes plus détaillés...................ou cerise sur le gateau lors d'une phase de REVERSE ENGINEERING, qui consiste à mettre à jour le/les modèle(s) à partir des modifications effectuées directement dans le code du language d'implémentation (Java et C++ actuellement).

Voici ci-dessous le niveau de ces classes avec les références de GRADY BOOCH vers 2000 et mes adaptations:

Voir maintenant une partie du même niveau de ces classes avec le formalisme UML2 dans Eclipse :

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

Modélisation des Classes

Il faut bien se souvenir des quelques règles du langage pour établir ou lire un diagramme de classes SysML/UML ,

On résume la  présentation graphique des classes et des objets  créés dans ces classes sur les deux figures ci-dessous.

Avec UML, le Nom d'une classe commence toujours par une Majuscule et celui d'un objet est souligné

On résume ci-dessous les représentations des classes et des objets sous une forme générique :

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

 Il va être question ici de concepts "Mesurables" par opposition aux réactions "Comportementales"   des JOUEURS qui sont, elles,  trop souvent imprévisibles !!!

Lors de mes contacts réguliers avec les joueurs de tous les niveaux qui peuplent les clubs de Bridge, je suis toujours médusé face aux contre vérités qui sont assénées, avec force et conviction, par des joueurs dont le passé universitaire est bien plus copieux que le mien, mais qui ont totalement oublié leurs formations de base en Probabilités.

Pour moi qui possède un long passé d'autodidacte, faute de la possibilité d'études scolaires dans mon adolescence, je me reporte très souvent à mes études volontaristes ultérieures pour consolider mon raisonnement au bridge, en ne me limitant pas aux recettes toutes faites. Il est nécessaire que je revalide les justifications d'une règle pour que je puisse l'utiliser ensuite en toute confiance!

C'est pour cette raison que je suis enthousiaste face au travail remarquable de Bernard CHARLES et Jérome GIGAULT qu'ils on réalisé en 2006 à la demande de la F.F.B pour consolider les choix des conventions définies depuis des années dans le S.E.F

Je propose sur ce site mon tableau personnel de synthèse pour ceux qui me croirons sur parole, pour les autres ils se reporteront au document officiel des auteurs qui est à mon avis totalement rigoureux et mathématiquement incontestable.

Le document complet des auteurs est disponible ici : http://www.bridge-gr-expert-ia.fr/index.php#

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

Double Dummy Solver (SOLVEUR DOUBLE MORT) dit DDS

                Introduction

                L'appellation  "Double Dummy Solver" est très bien connue d'un bon nombre d'expert du bridge, mais peu connue du plus grand nombre des bridgeurs qui ne veulent ou ne peuvent pas en analyser son concept pourtant simple dans son principe. En effet je suis toujours très surpris par les contre vérités qui circulent dans les salles de bridge, que je fréquente assidument depuis des années, sur la notion de PAR au bridge qui lui est une conséquence importante de ce concept et de l'algorithme de recherche associé, aujourd'hui quasi infaillible.

                Concept du double mort

                Pour comprendre cette dénomination il suffit de se mettre à la place d'un déclarant qui doit jouer un contrat quelconque, que sa ligne a choisi, lorsqu'il se trouve en face de son MORT avec lequel il doit réaliser son contrat. Dans cette position le déclarant connait deux mains soit 26 cartes, sur les 52 du jeu, et son problème va consister à reconstituer au fur et à mesure des levées la composition réelle des DEUX AUTRES mains cachées du camp adversaire. Si l'on IMAGINE UN MORT SUPPLEMENTAIRE composé d'une des deux mains cachées.............alors le déclarant pourrait chercher à résoudre son problème à CARTES OUVERTES car il aurait la connaissance de l'emplacement réel des 52 cartes du Jeu; d'où cette notion de DOUBLE MORT qui permet de tenter de résoudre la séquence des levées à réaliser en choisissant les bonnes impasses (s'il y en a à faire) et d'une manière plus générale la ligne de jeu à utiliser.

                Définition du  'SOLVER ' ou algorithme de recherche

                Bien sur, la connaissance de l'emplacement des cartes n'est qu'une étape vers le choix de la ligne de jeu optimale et le PAR éventuel, encore faut-il déterminer ce qui est réalisable ou pas et cela pour les QUATRE POSITIONS des joueurs à la table et dans les cinq COULEURS des contrats possibles sur les paliers de UN à SEPT. Ce travail algorithmique a été commencé er optimisé par BO HAGLUND depuis plus de 15 ans pour aboutir à une résolution logicielle du problème dont les outils sont disponibles en utilisation libre pour les joueurs qui souhaitent les utiliser (voir la référence 5, en fin de cet article).

                Les références 1 et 2 renvoient aux descriptions de l'algorithme, par son auteur avec tout sont historique d'évolution. La référence au site de J.BRAMDETZ permet d'obtenir un document , en français de Joel, qui décrit de quelle manière il est possible de minimiser le nombre des  arbres de recherche qui foisonneraient sans des simplifications dites  "intuitives".

                 LE PAR d'une donne

                Le calcul du PAR d'une donne est directement lié au "TOPAGE" et au nombre de levées réalisables sur chaque couleur et dans chaque position de joueurs. Ce calcul n'est qu'un sous produit qui découle des levées réalisables dans les deux axes.

                On notera ici que les simultanés des RONDES de FRANCE fournissent souvent ce type de résultats sur les feuilles de duplication de chaque donne ou alors les enchères à la française qui possibles mais jamais les deux simultanément;; aucune explication n'est ajoutée ce qui n'incite pas les joueurs à en comprendre les raisons!!! Ces simultanés utilisent le Logiciel Payant MAGIC CONTEST et fournissent ainsi en temps réel une information importante aux joueurs pour comparer leur choix sur la donne par rapport à l'optimum de possible............sans intégrer bien sur les erreurs des uns et des autres. On comprendra ainsi mieux l'intérêt technique des R.D.F. par rapport à des tournois de régularité ou l'étalonnage des contrats possibles est inconnu!!!!!!!

                Les bridgeurs de compétition noteront aussi que les épreuves fédérales ou de comité fournissent en fin de séance toutes ces informations.

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

Programmation en Langage Orienté Objet

Dans le domaine de la programmation moderne, nurse les experts ne conçoivent plus d’utiliser des méthodes de Programmation avec un langage qui ne soit pas Orienté Objet (P.O.O), viagra order  sauf si le programme final doit respecter des contraintes de temps réel très pointues. Dans la majorité des domaines domaine que les utilisateurs côtoient tous les jours, cette contrainte n’existe pas, et c’est bien sur le cas du BRIDGE (notre passion prioritaire ici), qui est un système très compliqué ou la notion de délais de réponse est inexistante. Le temps réel est réservé au processus industriels ou militaires contraints.

Le concept de langage Orienté Objet est une avancée majeure pour la conception des systèmes sophistiqués modernes, car il permet une approche plus simple de la complexité du domaine (du MONDE) à traiter en encapsulant (en masquant) cette complexité dans l’objet lui-même. De plus, il permet de mieux cerner les interactions entre les objets en termes d’inférences des une sur les autres.

Je ne peux ici que recommander, pour ne pas dire que cela est incontournable, de lire l’ouvrage majeur sur ce concept,  et les manières de le traiter, qui est traduit en français et qui s’intitule : Conception Orientée Objet et applications de GRADY BOOCH (voir ma bibliographie). Ce livre, écrit il y a déjà 20 ans, fut pour moi une livre de chevet indispensable au cours de ma carrière professionnelle internationale sur l’Ingénierie des Systèmes Informatiques Complexes.

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

Sous-catégories