Différences

Ci-dessous, les différences entre deux révisions de la page.

--- departement_info:personnels:pb:r4.01 [2023/03/03 10:55] – Brutus Philippe
+++ departement_info:personnels:pb:r4.01 [2025/02/27 14:25] (Version actuelle) – Brutus Philippe
@@ Ligne 15: / Ligne 15: @@
 Le serveur peut être un SGBD et le client lui envoie des requêtes SQL. Le serveur peut être une application spécifique qui répond à des requêtes exprimées dans un langage qui lui est propre (par exemple un serveur de calcul qui répond à des opérations). On parle alors d'architecture à 2 niveaux ou 2-tiers.
-{{:departement_info:personnels:pb:R4.01:2-tiers-1.png}}
+{{:departement_info:personnels:pb:R4.01:2-tiers-1.png?400x0&nolink}}\\
+{{:departement_info:personnels:pb:R4.01:2-tiers-2.png?400x0&nolink}}
-{{:departement_info:personnels:pb:R4.01:2-tiers-2.png}}
 Si le serveur est une application avec son propre langage de requêtes et que ce serveur interroge un autre serveur pour pouvoir répondre à son client, on parle d'architecture à 3 niveaux ou 3-tiers.
-{{:departement_info:personnels:pb:R4.01:3-tiers.png}}
+{{:departement_info:personnels:pb:R4.01:3-tiers.png?650x0&nolink}}
 Au delà de 3 niveaux, on parle d'architecture n-tiers.
@@ Ligne 29: / Ligne 28: @@
 Une application (web ou de bureau) est constituée de différents éléments ou composants logiciels. Ils se distinguent par leur rôle et la séparation des rôles permet une meilleure compréhension et une maintenance facilitée. Pour les applications avec une interface graphique, on retrouve l'architecture Modèle-Vue-Contrôleur (vue en IHM).
-{{:departement_info:personnels:pb:R4.01:2-tiers-1.png}}
+{{:departement_info:personnels:pb:R4.01:MVC.png?400x0&nolink}}
-C'est un patron d'architecture et il en existe d'[[https://fr.wikipedia.org/wiki/Patron_d%27architecture|autres]].
+C'est un patron d'architecture et il en existe [[https://fr.wikipedia.org/wiki/Patron_d%27architecture|d'autres]].
-On peut aussi concevoir une application en sous-ensembles distincts s'appuyant les uns sur les autres. On parle alors d'[[https://fr.wikipedia.org/wiki/Architecture_en_couches|architecture en couches]].
+On peut aussi concevoir une application en sous-ensembles de sous-programmes s'appuyant les uns sur les autres. On parle alors d'[[https://fr.wikipedia.org/wiki/Architecture_en_couches|architecture en couches]]. Ce principe est très utilisé dans les systèmes d'exploitation ([[https://courstechinfo.be/OS/StructureEnCouches.html|structure en couches]]) et dans les communications dans les réseaux informatiques ([[https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI|modèle OSI]]).
 Certains composants d'une application sont parfois partagés avec d'autres applications (traitement de texte et application de présentation peuvent partager le même correcteur orthographique par exemple). Les éléments constituant une application sont stockés sous forme de fichiers distincts et contiennent des sous-programmes susceptibles d'être utilisés dans l'application. Une bibliothèque logicielle est un ensemble de sous-programmes ou routines, généralement autour du même sujet, stockés dans un fichier. La bibliothèque utilisée par une application y est référencée mais elle n'est pas contenue dans le(s) fichier(s) du programme. Par cette technique,\\
@@ Ligne 39: / Ligne 38: @@
  - différentes applications peuvent utiliser la même bibliothèque.
-== Le projet ==
+=== Le projet ===
+Il s'agit de développer une application utilisant une base de données. L'architecture retenue est de type client-serveur mais l'accès à la base de données se fera via un composant logiciel assurant l'interface entre l'application de bureau (le client) et le SGBD (le serveur). Ce composant pourra être développé en sollicitant le SGBD par des requêtes SQL ou en utilisant une bibliothèque disponible sur le marché (ici [[https://www.devart.com/linqconnect/|LINQconnect Express]] qui met en oeuvre [[http://igm.univ-mlv.fr/~dr/XPOSE2009/Linq/index.html#choix|Language INtegrated Query]]). L'intérêt d'un tel composant d'interface est de rendre le client indépendant du support de données (voir le patron de conception procuration - //proxy//).
+{{:departement_info:personnels:pb:R4.01:sujet2024-2025.pdf|sujet}}\\
+{{:departement_info:personnels:pb:R4.01:fenetres2024-2025.pdf|exemples de fenêtres}}
+== Travail à réaliser ==
+/!\ Attention : l'évaluation impose de réaliser le travail en respectant les attendus de chaque séance.
+Séance 1 :
+  Création de la base de données (1pt)
+  Création de la solution et des projets (1pt)
+  Ajout de l’outil LinQ (1pt)
+  Création de la vue principale (vue de consultation) (3pts)
+  Création de la vue de configuration des paramètres de la base de données (1pt)
+  Connexion à la base de données (settings) (3pts)
+Séance 2 :
+  Affichage de la liste des sports (1pt)
+  La sélection d’un sport permet d’afficher les tournois associés à ce sport (2pts)
+  La sélection d’un tournoi permet d’afficher la liste des noms des participants. (2pts)
+  Un menu recherche participant permet d’ouvrir une fenêtre pour afficher tous les participants avec l’ensemble des informations dans un DataGrid. On peut alors trier par ordre alphabétique des noms ou rechercher par tout ou partie du nom. (5pts)
+Séance 3 :
+  Création de la vue d’authentification du gestionnaire (1pt)
+  Test de l’authentification (menus du gestionnaire activés) (1pt)
+  Création de la vue de gestion d’un tournoi (1pt)
+  Création de la vue de gestion d’un sport (1pt)
+  Ajout d’un tournoi et d’un sport (2pts)
+  Création de la vue gestion des participants (1pt)
+  Ajout d’un participant (3pts)
+Séance 4 :
+  Vues complétées de gestion des tournois, sports ou participants afin de pouvoir modifier ou supprimer un tournoi, un sport ou un participant à l’aide d’un ContextMenu (2pts)
+  Création de la fenêtre de gestion des gestionnaires de l’application (1pt)
+  Ajout d’un gestionnaire (2pts)
+  Modification ou suppression d’un gestionnaire à l’aide d’un ContextMenu (2pts)
+== Compte-rendu ==
-Il s'agit de développer une application utilisant une base de données. L'architecture retenue est de type client-serveur mais l'accès à la base de données se fera via un composant logiciel assurant l'interface entre l'application de bureau (le client) et le SGBD (le serveur). Ce composant pourra être développé ou consister en une bibliothèque disponible sur le marché (ici [[https://www.devart.com/linqconnect/|LINQconnect Express]] qui met en oeuvre [[http://igm.univ-mlv.fr/~dr/XPOSE2009/Linq/index.html#choix|Language INtegrated Query]]). L'intérêt d'un tel composant d'interface est de rendre le client indépendant du support de données.
-{{:departement_info:personnels:pb:R4.01:GestionBddEditeur.pdf|sujet}}
+Le travail réalisé au cours des 4 séances fera l'objet d'un compte-rendu écrit unique comportant les points suivants :
-{{:departement_info:personnels:pb:R4.01:BdD.zip|scripts de création de la base}}
+  * présentation du TP, c'est-à-dire introduction résumant le projet
+    * nature de l'application (client lourd ou application de bureau cliente plutôt qu'application web)
+    * objet ou vocation
+    * catégories d'utilisateurs
+    * fonctionnalités
+  * présentation des outils utilisés
+  * description de la classe BdDTournois
+  * description des tests réalisés (manuels ou automatisés), des corrections éventuelles et résultats obtenus
+  * conclusion
+    * fonctionnalités non développées
+    * fonctionnalités complémentaires à développer
+    * intérêt d'un ORM (Object Relational Mapper) tel que LinQ
+    * et surtout, en adéquation avec le thème d'architecture logicielle, l'intérêt de l'architecture client-serveur (votre application et le SGBD) et d'une architecture en couches pour le client lourd :
+      * couche interface utilisateur avec architecture MVC (ou variante de MVC)
+      * couche mots-clés "métier" avec la bibliothèque proposant différents services (obtenir les tournois, les sports, les participants, ajouter un sport, un tournoi... obtenir les participants d'un tournoi...)
+      * couche technique avec la bibliothèque externe LinQ