M15

ROYAUME DU MAROC

OFP .1 OFPP PTT

Office de la Formation Professionnelle et de la Promotion du Travail

RESUME THEORIQUE & GUIDE DES TRAVAUX PRATIQUES MODULE N° : TITRE DU MODULE : CONCEPTION

TECHNIQUE D’UNE APPLICATION

SECTEUR : NTIC SPECIALITE : TSDI Niveau : TECHNICIEN Spécialisé

1/49

2/49

REMERCIEMENT La DRIF remercie les personnes qui ont contribué à l’élaboration du présent document. Pour la supervision :

MME.BENNANI WAFAE M. ESSABKI NOURDDINE

DIRECTRICE CDC TERTIAIRE & TIC CHEF DE DIVISION CCFF

Pour la conception :

- MR HAJOUJI ABDELMOUNAIM

Pour la validation : - MR JELLAL ABDELILAH

Les utilisateurs de ce document sont invités à communiquer à la DRIF toutes les remarques et suggestions afin de les prendre en considération pour l’enrichissement et l’amélioration de ce programme. Said Slaoui DRIF

3/49

Introduction Les évolutions récentes dans le monde de l'informatique (taille et nature des logiciels, ouverture réseau, etc…) créent une demande croissante de la part de l'industrie de concepteurs informaticiens. Pour diverses raisons, la conception est généralement enseignée après la programmation. Quelque soit la démarche, il est indispensable d'enseigner les deux : la programmation et la conception. Ces deux domaines renforcent et appuient les points suivants : • • •

les bases de l'informatique (programmation, algorithmique et structures de données) sont indispensables ; la programmation orientée-objet est complexe et nécessite une attention particulière ; il est impératif que les stagiaires puissent mener au moins un << projet >> de A à Z.

Les systèmes informatiques deviennent de plus en plus grands et complexes. Ils ne peuvent plus être conçus, réalisés et maintenus par une seule (ou un nombre réduit de) personne(s). D'où la nécessité de former nos stagiaires au travail d'équipe et à la gestion des projets également. La production du logiciel implique des environnements de développement, avec toute la variété d'outils et d'approches dont on peut disposer, les méthodes et les techniques de gestion de processus, mais aussi les aspects humains au sein de l'équipe de développement et les relations que celle-ci entretient avec les commanditaires et les utilisateurs du produit.

4/49

Cycle de vie du logiciel Le développement et l'évolution d'un logiciel doit être vu comme un processus, appelé un peu abusivement le processus du logiciel (software process). Ce processus est composé de sousprocessus qui communiquent entre eux et dont certains évoluent en parallèle. Chaque processus peut être caractérisé par ses conditions de déclenchement, les activités déployées, les ressources utilisées, les produits résultants et ses critères de terminaison. Les activités faisant partie d'un processus peuvent à leur tour être décomposées en activités et tâches plus élémentaires. Le processus du logiciel peut être l'objet d'observations (qu'est-ce qui se fait dans la pratique?) ou d'études théoriques (comment faut-il procéder?). Il n'existe pas qu'un seul processus du logiciel, ni en pratique, ni en théorie, pour des raisons multiples: la diversité des applications informatiques et des logiciels relatifs, la disparité entre les méthodes, techniques et outils (y compris les langages de programmation) utilisés pour développer des logiciels, et enfin les différences de "culture" et d'habitude aussi bien des organisations que des personnes. On pourrait aussi définir le génie logiciel en disant que son objet est l'étude, la modélisation et la mise en pratique du processus du logiciel. La figure 1 montre l'ensemble des processus et sous-processus que le groupe de travail de l'ISO, ISO/JTC 1/SC7/WG3, a retenu pour l'architecture du processus du logiciel, et qui inclut les propositions du groupe de travail P1074 de l'organisation américaine IEEE, largement reprise par la norme [10]

5/49

Modélisation du cycle de vie du logiciel (software life cycle model) Gestion de projet (project management) Initiation du projet (project initiation) Pilotage et suivi du projet (project monitoring and control) Gestion de qualité du logiciel (software quality management) Pré-développement (pre-development) Besoins de l'utilisateur ou du système (user/system requirements) Conception du système (system design) Développement (development) Besoins en logiciels (software requirements) Conception architecturale (architectural design) Conception détaillée (detailed design) Codage (code) Intégration (integration) Réception du logiciel (software acceptance) Intégration du système (system integration) Test de terrain (field test) Post-développement (post-development) Installation (installation and checkout) Exploitation (operation) Maintenance et support du logiciel (software maintenance and support) Retrait (retirement) Processus globaux (integral processes) Vérification et validation (verification and validation) Gestion de la configuration du logiciel (software configuration management) Développement de la documentation (documentation development) Formation (training)

Fig. 1 Architecture du processus du logiciel (Software process architecture, ISO/JTC1/SC7/WG3) Le terme processus du logiciel est relativement récent. Il est presque synonyme de cycle de vie du logiciel (software life cycle), terme qui privilégie, peut-être un peu trop exclusivement, une vision temporelle du processus du logiciel. De façon générale, on peut dire que le cycle de vie du logiciel est la période de temps s'étalant du début à la fin du processus du logiciel. Il commence donc avec la proposition ou la décision de développer un logiciel et se termine avec sa mise hors service. Quand on subdivise le cycle de vie, on obtient des phases (phase), des étapes (stage) et des sous-étapes (step). Mais cette vision purement temporelle du cycle de vie est trop simplificatrice. De fait, une description ou modélisation du cycle de vie précise bel et bien les activités à entreprendre, le moment où il faut les entreprendre et les dépendances entre ces activités (fig. 4). Vu sous cet angle, les notions de processus du logiciel et de cycle de vie du logiciel sont très proches. La partie du cycle de vie consacrée au développement à proprement parler s'appelle le cycle de développement du logiciel (software development cycle) et correspond au processus de développement du logiciel (software development process). Le cycle de développement du logiciel commence avec la décision de développer un logiciel et se termine avec la livraison du logiciel et son installation. Nous commencerons par décrire les activités qui précèdent et qui suivent le cycle de développement, ce dernier faisant l'objet d'une section particulière.

6/49

Le développement est précédé d'une phase préparatoire que nous appellerons avant-projet (concept exploration) et qu'on nomme aussi étude d'opportunité ou étude préalable. Cette phase a comme objectif de répondre aux questions suivantes: · pourquoi développer le logiciel ? · comment procéder pour faire ce développement ? · quels moyens faut-il mettre en oeuvre ? Elle comprend à la fois des aspects techniques et de gestion. Parmi les tâches techniques, groupées sous le terme étude préalable, on peut citer: · dresser un état de l'existant et faire une analyse de ses forces et faiblesses; · identifier les idées ou besoins de l'utilisateur; · formuler des solutions potentielles; · faire des études de faisabilité; · planifier la transition entre l'ancien logiciel et le nouveau, s'il y a lieu; · affiner ou finaliser l'énoncé des besoins de l'utilisateur. La préparation de la gestion du projet est appelée initiation du projet (project initiation), et comprend les tâches suivantes: · représenter les activités à entreprendre dans un modèle; · prévoir les ressources nécessaires au projet; · mettre en place les environnements de développement et de support; · identifier les procédures et normes spécifiques au projet et les mesures à mettre en place pour contrôler leur application; · planifier la gestion du projet. Le résultat de l'avant-projet est consigné dans un document appelé cahier des charges du projet ou spécification du projet (project specification). Celui-ci énonce donc les spécifications techniques, administratives et financières du but, des besoins, de la portée et des limites du projet, ainsi que ses relations avec d'autres projets. Une fois que le logiciel a été développé, il sera mis en exploitation. Entre les deux se situe une phase transitoire, appelée installation. Elle est en général prise en charge par l'équipe de développement pour un logiciel fait sur mesure, en particulier pour un développement interne. A l'opposé, pour un logiciel à large diffusion, l'acheteur se charge de l'installation, éventuellement avec l'assistance du service après-vente du distributeur. Quoi qu'il en soit, l'installation comprend les tâches suivantes: · planifier l'installation; · distribuer le logiciel; · installer le logiciel et son environnement (cadre organisationnel, matériel, données); · vérifier le logiciel dans son environnement opérationnel; · mettre hors service tout logiciel censé avoir été remplacé par le nouveau logiciel; · mettre en place des mises à jour. Après l'installation suit la phase d'exploitation et de maintenance (operation and maintenance phase). Le logiciel est maintenant employé dans son environnement opérationnel, son comportement est surveillé et, si nécessaire, il est modifié. Cette dernière activité s'appelle la maintenance du logiciel (software maintenance). Il peut être nécessaire de modifier le logiciel pour corriger des défauts, pour améliorer ses performances ou autres caractéristiques, pour adapter le logiciel à un nouvel environnement ou pour répondre à des nouveaux besoins ou à des

7/49

besoins modifiés. On peut donc distinguer entre la maintenance corrective, la maintenance perfective et la maintenance adaptative. Sauf pour des corrections mineures, du genre dépannage, la maintenance exige en fait que le cycle de développement soit réappliqué, en général sous une forme simplifiée. Une fois qu'une version modifiée du logiciel a été développée, il faut bien entendu la distribuer. De plus, il est en général nécessaire de fournir à l'exploitant du logiciel une assistance technique et un support de consultation. En résumé, on peut dire que la maintenance et le support du logiciel comprennent les tâches suivantes: · effectuer des dépannages pour des corrections mineures; · réappliquer le cycle de développement pour des modifications plus importantes; · distribuer les mises à jour; · fournir l'assistance technique et un support de consultation; · maintenir un journal des demandes d'assistance et de support. A un moment donné, on décide de mettre le logiciel hors service. Les tâches correspondantes sont accomplies durant la phase de retrait (retirement phase) et comprennent: · avertir les utilisateurs; · effectuer une exploitation en parallèle du logiciel à retirer et de son successeur; · arrêter le support du logiciel.

8/49

9/49

Cycle de développement du logiciel Après avoir passé en revue la phase qui le précède et les phases qui lui succèdent, nous pouvons revenir sur le cycle de développement du logiciel (fig. 4 ). Un certain nombre d'activités accompagnent nécessairement tout le cycle de développement: la gestion du projet, la vérification et validation, le développement de la documentation, la gestion de la configuration, et la formation. Nous allons commencer par décrire ces activités et nous parlerons plus tard des phases du cycle de développement. La gestion du projet (project management) comprend l'affinement et les modifications de la planification du projet, le pilotage et le suivi du projet, et la gestion de la qualité. La planification du projet (project planning) a comme buts de générer une décomposition du projet en activités et tâches plus élémentaires ayant des interrelations minimales, et de produire une structure de référence pour le pilotage et le suivi du projet. Elle définit donc les tâches, le calendrier, les ressources, l'allocation de ces ressources aux tâches et les procédures du projet. Le pilotage et le suivi du projet (project monitoring and control) consiste à enregistrer les faits sur l'avancement du projet, à comparer cet avancement avec la planification, et à entreprendre, si nécessaire, des mesures correctives. La gestion de la qualité du logiciel (software quality management) comprend l'ensemble des activités de gestion déployées pour garantir que le processus de développement engendre un produit de qualité. Il s'agit en quelque sort du processus qui pilote les activités de vérification et de validation, dont la nature est technique et dont nous avons déjà parlé. La gestion de la qualité du logiciel comprend donc les tâches suivantes: · planifier le programme de qualité; · implémenter un système de comptes-rendus de problèmes et d'actions correctives; · définir un programme pour mesurer la qualité; · piloter et contrôler l'application du programme de qualité; · recommander des améliorations pour les programmes de qualité futurs. L'exécution du programme de qualité est prise en charge par les activités de vérification et de validation qui sont les suivantes: · déterminer les produits à évaluer et les procédures d'évaluation; · collectionner et analyser les informations; · planifier l'effort de test; · développer des spécifications et procédures de test; · faire les vérifications et validations, et exécuter les tests. La gestion de la qualité du logiciel et les activités de vérification et de validation sont parfois regroupées sous le terme assurance de qualité du logiciel (software quality assurance, SQA). La documentation (documentation) est un élément essentiel dans le développement d'un logiciel: elle fait partie du produit à réaliser; elle matérialise l'avancement des travaux, car chaque phase est concrétisée par la production d'un ou plusieurs documents; elle constitue le support de communication entre les différents intervenants du projet. On peut distinguer trois types de documents: les documents de gestion du projet, les documents techniques de réalisation, les manuels d'utilisation et d'exploitation. La documentation de développement et le logiciel lui-même sont constitués d'un grand nombre d'éléments qui évoluent durant tout le cycle de vie. Le but de la gestion de la configuration (configuration management) est de maîtriser cette évolution. La gestion de la configuration comprend donc l'ensemble des activités suivantes:

10/49

· identifier et définir les éléments de configuration et toutes leurs relations; · archiver les éléments de configuration, aussi bien leurs états initiaux que leurs états successifs; · contrôler les modifications des éléments de configuration, ce qui inclut pour chaque modification: autoriser le changement, vérifier que le nouvel état est complet et cohérent, enregistrer le nouvel état, annoncer la modification, mettre à disposition le nouvel état. Les entités suivantes et leurs composants peuvent jouer le rôle d'éléments de configuration (configuration item), c'est-à-dire être pris en charge par la gestion de la configuration: · les documents de gestion du projet; · les documents techniques de réalisation; · les manuels d'utilisation et d'exploitation; · les programmes sources et les moyens permettant de produire et de reproduire le programme machine; · les jeux de données de tests, y compris leurs résultats, les procédures et scénarios de test. Identifier les éléments de configuration revient à opérer un choix parmi tous les éléments possibles et affecter à chaque élément retenu un identifiant. Cet identifiant doit être unique et doit permettre de déterminer la nature et la version de l'élément. Il faut également définir les liens entre les identifiants des éléments de configuration ce qui constitue la nomenclature du logiciel et de son développement.

Phases du cycle de développement Après avoir passé en revue les activités qui accompagnent tout le cycle de développement, nous allons maintenant présenter le découpage classique du cycle de développement en phases. Ce découpage correspond au modèle classique dite de la cascade (waterfall model). Tous les modèles du cycle de développement ne sont pas les mêmes, mais l'idée est toujours la même: le logiciel est développé en phases discrètes, chacune ayant un résultat défini et un critère de terminaison défini, et chaque phase est achevée avant que ne commence la suivante. Le modèle classique du cycle de développement(fig. 4) comprend les phases suivantes: analyse, conception, implémentation, test, et éventuellement phase d'installation, dont nous avons déjà parlé. D'autres noms sont parfois donnés à ces phases et un découpage plus fin est souvent utile. Chaque phase a des entrées et des sorties, qui sont généralement des documents et parfois des produits. Toute sortie d'une phase servira d'entrée à une phase ultérieure, souvent celle qui suit immédiatement, mais pas toujours. Certaines activités déployées pendant une phase lui sont donc spécifiques et d'autres sont destinées à préparer les phases qui suivent. Dérivé du modèle de la cascade, le modèle en V du cycle de développement (fig. 5) montre non seulement l'enchaînement des phases successives, mais aussi les relations logiques entre phases plus éloignées.

11/49

L'application stricte du modèle en phases prescrit qu'on complète entièrement une phase avant de passer à la suivante. Dans la pratique, il arrive cependant qu'au cours d'une phase on découvre des erreurs commises dans une phase antérieure ou même l'absence d'éléments essentiels qui auraient dû être fournis par une phase antérieure. Il peut donc être nécessaire de revenir sur une phase précédente. Si tel est le cas, il faut parcourir à nouveau toutes les phases à partir de la phase révisée pour répercuter partout les modifications. Lors de la phase d'analyse, également appelée phase de spécification (requirements phase, analysis phase, definition phase), on analyse les besoins de l'utilisateur ou du système englobant et on définit ce que le logiciel devra faire. Le résultat de la phase d'analyse est consigné dans un document appelé cahier des charges du logiciel (à ne pas confondre avec le cahier des charges du projet) ou spécification du logiciel, en anglais: software requirements, software specification ou requirements specification. La spécification représente un modèle de ce qui est nécessaire et un énoncé du problème pris en compte. La spécification est élaborée par une approche itérative de modélisation et d'analyse de la réalité modélisée. Une spécification est en général non constructive: elle n'est donc pas une solution du problème. On peut encore dire qu'une spécification présente une vue externe du logiciel, c'est-à-dire tout ce qui peut être perçu sans pénétrer dans la structure interne du logiciel. Il est essentiel qu'une spécification ne définisse que les caractéristiques essentielles du logiciel pour laisser de la place aux décisions de conception. Souvent la spécification est donc intentionnellement vague dans les domaines où des détails supplémentaires sont impossibles ou non pertinents. En effet, la spécification excessive, appelée surspécification, peut induire des augmentations substantielles des coûts de développement et des inefficacités dans l'utilisation et l'exécution d'un logiciel, car des solutions mieux adaptées sont exclues par la surspécification. Une spécification comporte les éléments suivants: · description de l'environnement du logiciel;

12/49

· spécification fonctionnelle (functional specification), qui définit toutes les fonctions que le logiciel doit offrir; · comportement en cas d'erreurs, c'est-à-dire dans les cas où le logiciel ne peut pas accomplir une fonction; · performances requises (performance requirements), par exemple temps de réponse, encombrement en mémoire, sécurité de fonctionnement; · interfaces avec l'utilisateur (user interface), en particulier le dialogue sur terminal, la présentation des écrans, la disposition des états imprimés, etc. · interfaces avec d'autres logiciels; · interfaces avec le matériel; · contraintes de réalisation, telles que l'environnement de développement, le langage de programmation à utiliser, les procédures et normes à suivre, etc. Il est judicieux de préparer pendant la phase d'analyse les procédures qui seront mises en oeuvre pour vérifier que le logiciel, une fois construit, est conforme à la spécification. Cette évaluation peut revêtir plusieurs formes et comprendre plusieurs activités, en particulier l'exécution de tests. Pour notre part, nous l'appellerons test de réception (acceptance test). A ce stade du cycle de développement, le document correspondant a un caractère incomplet et comprend essentiellement un plan de test de réception. Durant la phase d'analyse, on produit également une version provisoire des manuels d'utilisation et d'exploitation du logiciel. Nous reviendrons plus tard sur le contenu de ces manuels. La phase d'analyse est suivie de la phase de conception (design phase), généralement décomposée en deux phases successives dont la première est appelée conception générale, conception globale, conception préliminaire ou conception architecturale (preliminary design ou architectural design), et la deuxième conception détaillée (detailed design). A partir du document de spécification, la phase de conception doit fournir une réponse à la question: "Comment réaliser le logiciel ?". Commençons par décrire les activités entreprises lors de la conception générale. Si nécessaire, il faut commencer par l'ébauche de plusieurs variantes de solutions et choisir celle qui offre le meilleur rapport entre coûts et avantages. Il faut ensuite figer la solution retenue, la décrire et la détailler. En particulier, il faut décrire l'architecture de la solution, c'est-à-dire son organisation en entités, les interfaces de ces entités et les interactions entre ces entités. Ce processus de structuration doit être poursuivi jusqu'à ce que tous les éléments du document de spécification ont été pris en compte. Le résultat de cette démarche est un document de conception générale. Durant la phase de conception générale, il faut également préparer la phase d'intégration. A cet effet, il faut élaborer un plan d'intégration, y compris un plan de test d'intégration. La conception détaillée affine la conception générale. Elle commence par décomposer les entités découvertes lors de la conception générale en entités plus élémentaires. Cette décomposition doit être poursuivie jusqu'au niveau où les entités sont faciles à implémenter et à tester, c'est-à-dire correspondent à des composants logiciels élémentaires. Ce niveau dépend fortement du langage de programmation retenu pour l'implémentation: le niveau ne sera pas le même pour un langage de quatrième génération, un langage procédural classique ou un langage d'assemblage. Il faut ensuite décrire chaque composant logiciel en détail: son interface, les algorithmes utilisés, le traitement des erreurs, ses performances, etc. L'ensemble de ces descriptions constitue le document de conception détaillée. Pendant la conception détaillée, il faut également préparer la vérification des composants logiciels élémentaires qui fera l'objet de la phase des tests unitaires. Le résultat est consigné dans

13/49

un document appelé plan de tests unitaires. Si nécessaire, il faut de plus compléter le plan d'intégration, car de nouvelles entités ont pu être introduites pendant la conception détaillée. Après la conception détaillée, on peut passer à la phase d'implémentation, également appelée phase de construction, phase de réalisation ou phase de codage (implementation phase, construction phase, coding phase). Lors de cette phase, la conception détaillée est traduite dans un langage de programmation. Il faut également préparer les données nécessaires à l'exploitation du logiciel, soit en les saisissant, soit en convertissant des données déjà existantes. La phase d'implémentation fournit donc les composants logiciels sur support informatique; on peut citer les sources et objets compilés, les comptes-rendus des résultats de compilation, les références croisées internes et externes des composants. Elle doit également fournir une liste des commandes de production du logiciel, par exemple les commandes de compilation, et une description de l'environnement de production. La phase d'implémentation est suivie de la phase de test (test phase). Durant cette phase, les composants du logiciel sont évalués et intégrés, et le logiciel lui-même est évalué pour déterminer s'il satisfait la spécification élaborée lors de la phase d'analyse. Cette phase est en général subdivisée en plusieurs phases. Lors des tests unitaires (unit test), on évalue chaque composant individuellement pour s'assurer qu'il est conforme à la conception détaillée. Si ce n'est déjà fait, il faut élaborer pour chaque composant un jeu de données de tests. Il faut ensuite exécuter le composant avec ce jeu, comparer les résultats obtenus aux résultats attendus, et consigner le tout dans le document des tests unitaires. S'il s'avère qu'un composant comporte des erreurs, il est renvoyé à son auteur, qui devra diagnostiquer la cause de l'erreur puis corriger le composant. Le test unitaire de ce composant est alors à reprendre. Après avoir effectué avec succès les tests unitaires de tous les composants, on peut procéder à leur assemblage, qui est effectué pendant la phase d'intégration (integration phase). Pendant cette phase, on vérifie également la bonne facture des composants assemblés, ce qu'on appelle le test d'intégration (integration test). On peut donc distinguer les actions suivantes: construire par assemblage un composant à partir de composants plus petits; exécuter les tests pour le composant assemblé et enregistrer les résultats; comparer les résultats obtenus aux résultats attendus; si le composant n'est pas conforme, engager la procédure de modification; si le composant est conforme, rédiger les comptes-rendus du test d'intégration et archiver sur support informatique les sources, objets compilés, images exécutables, les jeux de tests et leurs résultats. Après avoir intégré le logiciel, on peut l'installer dans son environnement d'exploitation, ou dans un environnement qui simule cet environnement d'exploitation, et le tester pour s'assurer qu'il se comporte comme requis dans la spécification élaborée lors de la phase d'analyse. Cette phase s'appelle la phase d'installation (installation phase ou installation andcheck-out phase). Les tests effectués durant cette phase prennent des noms variés selon leur nature. On parle parfois de validation, comme la norme française Z 67-130 [6]. Si l'on veut insister sur le fait que ces tests doivent préparer la décision du mandant d'accepter ou non le logiciel, on utilise les termes test d'acceptance, test de recette ou test de réception (acceptancetest). Enfin, s'il s'agit de montrer le comportement et les performances du logiciel dans son environnement d'exploitation réel, le terme test d'exploitation est d'usage (operational test). Les manuels d'utilisation et d'exploitation doivent être prêts au plus tard lors de l'installation du logiciel. Selon la complexité de ce dernier, la documentation d'utilisation est organisée en un ou plusieurs documents qui pourraient être les suivants: · guide d'installation;

14/49

· manuel d'introduction ou guide de l'utilisateur; · manuel de référence; · mémento ou aide-mémoire; · manuel de l'opérateur. Dans ce texte, nous nous contentons de proposer un plan pour un document unique, appelé manuel de l'utilisateur (user's manual), largement inspiré de la norme française Z 67-122 [7]. Le document principal élaboré durant une phase prend souvent le même nom que la phase, éventuellement en ajoutant le mot document ou dossier pour éviter les confusions.

15/49

Interface homme-machine, les concepts Nous énumérons quelques principes utiles à l'élaboration d'une interface associée étroitement à la programmation événementielle. L’objectif des IHM est : • Faire écrire des programmes interactifs. Ce qui signifie que le programme doit communiquer avec l'utilisateur qui reste l'acteur privilégié de la communication. Une partie de la spécification des programmes s'effectue avec des objets graphiques représentant des classes (programmation objet visuelle). • Le programmeur peut découpler pendant la conception la programmation de son interface de la programmation des tâches internes de son logiciel (pour nous généralement ce sont des algorithmes ou des scénarios objets). Les spécialistes en ergonomie conceptualisent une IHM en six concepts : • les objets d'entrée-sortie, • les temps d'attente (temps de réponse aux sollicitations), • le pilotage de l'utilisateur dans l'interface, • les types d'interaction (langage,etc..) , • l'enchaînement des opérations, • la résistance aux erreurs (ou robustesse qui est la qualité qu'un logiciel à fonctionner même dans des conditions anormales). Un principe général provenant des psycho-linguistes guide notre programmeur dans la complexité informationnelle : la mémoire rapide d'un humain ne peut être sollicitée que par un nombre limité de concepts différents en même temps (nombre compris entre sept et neuf). Développons un peu plus chacun des six concepts composants une interface.

Les objets d'entrée-sortie Une IHM présente à l'utilisateur un éventail d'informations qui sont de deux ordres : des commandes entraînant des actions internes sur l'IHM et des données présentées totalement ou partiellement selon l'état de l'IHM. Les commandes participent à la " saisie de l'intention d'action" de l'utilisateur, elles sont matérialisées dans le dialogue par des objets d'entrée de l'information (boîtes de saisie,boutons, menus etc...). Voici un exemple d’objets visuels associés aux objets d'entrée de l'information , ils sont très proches visuellement des objets que l'on trouve dans la plus part des environnements de développement visuels, car en fait ce sont des surcouches logiciels de contrôles de base du système d'exploitation (qui est lui-même fenêtré et se présente sous forme d'une IHM dénommée bureau électronique).

16/49

Les données sont présentées à un instant précis du dialogue à travers des objets de sortie de l'information (boîte d'édition monoligne, multiligne, tableaux, graphiques, images, sonsetc...). Ci-dessous quelques objets visuels associés à des objets de sortie de l'information :

17/49

Les temps d'attente Sur cette question, une approche psychologique est la seule réponse possible, car l'impression d'attente ne dépend que de celui qui attend selon son degré de patience. Toutefois, puisque nous avons parlé de la mémoire à court terme (mémoire rapide), nous pouvons nous baser sur les temps de persistance généralement admis (environ 5 secondes). Nous considérerons qu'en première approximation, si le délai d'attente est : inférieur à environ une seconde la réponse est quasi-instantanée, compris entre une seconde et cinq secondes il y a attente, toutefois la mémoire rapide de l'utilisateur contient encore la finalité de l'opération en cours. lorsque l'on dépasse la capacité de mémorisation rapide de l'utilisateur alors il faut soutenir l'attention de l'utilisateur en lui envoyant des informations sur le déroulement de l'opération en cours (on peut utiliser pour cela par exemple des barres de défilement, des jauges, des boîtes de dialogue, etc...) Exemples de quelques classes d'objets visuels de gestion du délai d'attente :

L e pilotage de l'utilisateur Nous ne cherchons pas à explorer les différentes méthodes utilisables pour piloter un utilisateur dans sa navigation dans une interface. Nous adoptons plutôt la position du concepteur de logiciel qui admet que le futur utilisateur ne se servira de son logiciel que d'une façon épisodique. Il n'est donc pas question de demander à l'utilisateur de connaître en permanence toutes les fonctionnalités du logiciel. En outre, il ne faut pas non plus submerger l'utilisateur de conseils de guides et d'aides à profusion, car ils risqueraient de le détourner de la finalité du logiciel. Nous préférons adopter une ligne moyenne qui consiste à fournir de petites aides rapides contextuelles (au moment où l'utilisateur en a besoin) et une aide en ligne générale qu'il pourra consulter s'il le souhaite. Ce qui revient à dire que l'on accepte deux niveaux de navigation dans un logiciel : • le niveau de surface permettant de réagir aux principales situations, • le niveau approfondi qui permet l'utilisation plus complète du logiciel. Il faut admettre que le niveau de surface est celui qui restera le plus employé (l'exemple d'un logiciel de traitement de texte courant du commerce montre qu'au maximum 30% des fonctionnalités du produit sont utilisées par plus de 90% des utilisateurs). Pour permettre un pilotage plus efficace on peut établir à l'avance un graphe d'actions possibles du futur utilisateur (nous nous servirons du graphe événementiel) et ensuite diriger l'utilisateur dans ce graphe en matérialisant (masquage ou affichage) les actions qui sont réalisables.

Les types d'interaction Le tout premier genre d'interaction entre l'utilisateur et un logiciel est apparu sur les premiers systèmes d'exploitation sous la forme d'un langage de commande. L'utilisateur dispose d'une famille de commandes qu'il est censé connaître, le logiciel étant doté d'une interface interne

18/49

(l'interpréteur de cette famille de commandes). Dès que l'utilisateur tape textuellement une commande (exemple MS-DOS " dir c: /w "), le système l'interprète (dans l'exemple : lister en prenant toutes les colonnes d'écran, les bibliothèques et les fichiers du disque C). Nous adoptons comme mode d'interaction entre un utilisateur et un logiciel, une extension plus moderne de ce genre de dialogue, en y ajoutant, en privilégiant, la notion d'objets visuels permettant d'effectuer des commandes par actions et non plus seulement par syntaxe textuelle pure. Nous construisons donc une interface tout d'abord essentiellement à partir des interactions événementielles, puis lorsque cela est utile ou nécessaire, nous pouvons ajouter un interpréteur de langage (nous pouvons par exemple utiliser des automates d'états finis pour lareconnaissance).

L'enchaînement des opérations Nous savons que nous travaillons sur des machines de Von Neumann, donc séquentielles, les opérations internes s'effectuant selon un ordre unique sur lequel l'utilisateur n'a aucune prise. L'utilisateur est censé pouvoir agir d'une manière " aléatoire ". Afin de simuler une certaine liberté d'action de l'utilisateur nous lui ferons parcourir un graphe événementiel prévu par le programmeur. Il y a donc contradiction entre la rigidité séquentielle imposée par la machine et la liberté d'action que l'on souhaite accorder à l'utilisateur. Ce problème est déjà présent dans un système d'exploitation et il relève de la notion de gestion des interruptions. Nous pouvons trouver un compromis raisonnable dans le fait de découper les tâches internes en tâches séquentielles minimales ininterruptibles et en tâches interruptibles. Les interruptions consisteront en actions potentielles de l'utilisateur sur la tâche en cours afin de : • interrompre le travail en cours, • quitter définitivement le logiciel, • interroger un objet de sortie, • lancer une commande exploratoire ... Il faut donc qu'existe dans le système de développement du logiciel, un mécanisme qui permette de " demander la main au système " sans arrêter ni bloquer le reste de l'interface, ceci pendant le déroulement d'une action répétitive et longue. Lorsque l'interface a la main, l'utilisateur peut alors interrompre, quitter, interroger... Ce mécanisme est disponible dans les EDI visuels pédagogiques (Delphi,Visual Basic, Visual C#).Terminons ce tour d'horizon, par le dernier concept de base d'une interface : sa capacité à absorber certains dysfonctionnements.

La résistance aux erreurs Il faut en effet employer une méthode de programmation défensive afin de protéger le logiciel contre des erreurs comme par exemple des erreurs de manipulation de la part de l'utilisateur. Nous utilisons plusieurs outils qui concourent à la robustesse de notre logiciel. La protection est donc située à plusieurs niveaux. 1°) Une protection est apportée par le graphe événementiel qui n'autorise que certaines actions (activation-désactivation), matérialisé par un objet tel qu'un menu : l'item " taper un fichier " n'est pas activable l'item " Charger un fichier " est activable

19/49

2°) Une protection est apportée par le filtrage des données (on peut utiliser par exemple des logiciels d'automates de reconnaissance de la syntaxe des données). 3°) Un autre niveau de protection est apporté par les composants visuels utilisés qui sont sécurisés dans le RAD à l'origine. Par exemple la méthode LoadFromfile de Delphi qui permet le chargement d'un fichier dans un composant réagit d'une manière sécuritaire (c'est à dire rien ne se produit)lorsqu'on lui fournit un chemin erroné ou que le fichier n'existe pas. 4°) Un niveau de robustesse est apporté en Delphi par une utilisation des exceptions (semblable à JAVA ou à C++) autorisant le détournement du code afin de traiter une situation interne anormale (dépassement de capacité d'un calcul, transtypage de données non conforme etc...). Le programmeur peut donc prévoir les incidents possibles et construire des gestionnaires d'exceptions.

20/49

Création du modèle logique des données PRESENTATION L’objectif du développement du Modèle Conceptuel des Données (M.C.D.) représenté par le schéma Entités/Associations est non seulement une étude exhaustive des données du système d’informations, et des relations entre elles; mais aussi une implantation informatique qui doit nous permettre d’obtenir un système d’informations automatisé.Le modèle logique des données intègre donc comme contraintes techniques la prise en compte de l’outil logiciel d’implantation du modèle conceptuel de données. Remarque : il existe plusieurs types de modèles logiques dont : le modèle fichier le modèle relationnel le modèle hiérarchique le modèle réseaux (ou CODASYL) Il existe principalement deux techniques d’implantation informatique d’un système d’informations. Le modèle fichier (S.G.F.) Ce modèle a pour objectif la représentation du système d’informations sous forme d’un ensemble de fichiers informatiques de données (S.G.F. Système de gestion de fichiers), manipulés par un ensemble de programmes écrits en langage de programmation. exemple : utilisation du langage COBOL associé à des fichiers en organisation séquentielle indexée. Le modèle S.G.B.D.R On implante le système d’informations à partir d’un logiciel appelé Système de Gestion de Bases de Données Relationnel (S.G.B.D.R.). Le système d’informations devient alors une Base de Données, où les données sont représentées sous forme de tables, l’accès est possible à partir de requêtes d’interrogation de la base de données. Les S.G.B.D.R. offrent aussi un ensemble d’outils permettant d’assurer la sécurité, et la confidentialité des informations. exemple : S.G.B.D.R. : MS ACCESS avec le langage de requêtes QBE, SQL ACCESS, ou VBA S.G.B.D.R. : MS SQL Server avec SQL, SQL Transac, ou VB S.G.B.D.R. : ORACLE avec SQL, PL-SQL

21/49

Les règles de passage du MEA au MR. Les règles générales Le passage d’un modèle conceptuel de données représenté par le modèle entités/associations (M.E.A.) au modèle logique des données représenté par le modèle relationnel (M.R.) . Règle 1 : Les entités qui ne sont pas porteuses d’autres données que leur identifiant peuvent disparaître du modèle logique. Règle 2 : Les autres entités deviennent des relations dont la clé primaire est l’identifiant de l’entité. Règle 3 : Les associations hiérarchiques, de type Contrainte d’Intégrité Fonctionnel (C.I.F.) ou Dépendance Fonctionnelle simple (D.F.). soit de cardinalités (1/1 et 0 ou 1/N) disparaissent du modèle logique. L’identifiant de l’entité but (cardinalité 0 ou 1/N) devient clé étrangère dans la relation représentant l’entité source (cardinalité 1/1). Exemple : (CIF dépendance fonctionnelle forte)

COMMANDE (Numéro commande, date commande, CLIENT (Numéro client, Nom client, Adresse client) autres notations COMMANDE (Numéro commande, date commande, Numéro client*) Exemple : (DF dépendance fonctionnelle faible)

Numéro

client#)

EMPLACEMENT (Numéro d’emplacement, Surface, Nombre personne max, Type d’emplacement#) TYPE D’EMPLACEMENT (Type d’emplacement, Tarif de location) autres notations EMPLACEMENT (Numéro d’emplacement, Surface, Nombre personne max, Type d’emplacement*) Règle 4 : Les associations non hiérarchiques porteuses ou non de données deviennent des relations dont la clé primaire est la concaténation des identifiants des entités reliés par l’association.

EMPLOIE (Numéro projet#, Numéro employé#) PROJET (Numéro projet, Nom projet, Budget projet) EMPLOYE (Numéro employé, Nom Employé, prénom employé)

EMPLOIE (Numéro projet#, Numéro employé#, Nb heure travail) PROJET (Numéro projet, Nom projet, Budget projet) EMPLOYE (Numéro employé, Nom Employé, prénom employé) Exemple : règles 1, 2, et 4 sur une association reliant trois entités (ternaire)

22/49

DATE (Date d’ouverture) SERVEUR (Numéro serveur, Nom serveur, Prénom serveur) TABLE (Numéro table, capacité) EST_AFFECTE (Numéro serveur#, Numéro table#, Date d’ouverture#) Règle 5 : Cas des associations de cardinalités particulières. Les associations réflexives.

Solution 1 : On considère être en présence d’une association non hiérarchique (0/N,0/N), on applique de ce fait la règle 4 en prenant soin de renommer les parties composant la clé primaire de telle façon à ce que la sémantique du modèle conceptuel soit conservée. LIVRE (Code livre, titre, date d’édition) PRECEDE(Code livre#, Code livre Suivant#) Solution 2 : On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 en prenant soin de renommer la clé étrangère de telle façon à ce que la sémantique du modèle conceptuel soit conservée. LIVRE (Code livre, titre, date d’édition, Code livre Suivant#) Remarque : Le choix de la solution à retenir va dépendre du contexte. Si l’on considère qu’en règle générale peu de livre ont des suites on choisira la solution 1, dans le cas où l’on rencontre un livre qui est la suite d’un autre on crée une occurrence dans PRECEDE, ce qui évite une multitude de Code livre Suivant (table LIVRE) à vide si l’on avait choisi la solution 2.

On doit prendre soin de conserver la sémantique du mariage tel qu’il est défini par le contexte (actuellement en France hétérosexuel avec notion de femme, et mari) PERSONNE (Code personne, Nom, Prénom) MARIE (Code personne femme#, Code personne mari#, Date mariage) Remarque cette solution n'est pas optimum (contexte spécifique).

PERSONNE (Code personne, Nom, Prénom)

23/49

VILLE (Code Ville, Libellé ville) MARIE (Code personne femme#, Code personne mari#, Code Ville#, Date mariage) Remarque cette solution n'est pas optimum (contexte spécifique). Cardinalités spécifiques

ENTREPRISE(référence entreprise, raison sociale, adresse, code tuteur#) TUTEUR(code tuteur, nom, prénom, téléphone, référence entreprise#)

Solution 1 : On considère être en présence d’une association non hiérarchique (1/N,0/N), on applique de ce fait la règle 4. DEPARTEMENT(Numéro département, Budget département) EMPLOYE(Numéro employé, nom employé, prénom employé) DIRIGE(Numéro département#, Numéro employé#) Solution 2 : On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème DEPARTEMENT(Numéro département, Budget département, Numéro employé directeur#) EMPLOYE(Numéro employé, nom employé, prénom employé) Solution 3 : On considère être en présence d’une association non hiérarchique (1/1,1/1). DEPARTEMENT(Numéro département, Budget département, Numéro employé directeur#) EMPLOYE(Numéro employé, nom employé, prénom employé, Numéro département dirigé#)

Solution 1 : (absolument logique) On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème STAGE(Numéro stage, Libellé stage, Date stage, Durée stage, Numéro formateur responsable#) FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur) Solution 2 : On considère être en présence d’une association non hiérarchique (1/N,0/N), on applique de ce fait la règle 4. STAGE(Numéro stage, Libellé stage, Date stage, Durée stage) FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur) RESPONSABLE(Numéro stage#, Numéro formateur#)  adaptation à une possible modification de contexte de la responsabilité du stage.

Remarque : Cette modélisation peut être discutable (cas d’illustration).

24/49

Solution 1 : On considère être en présence d’une association hiérarchique (1/1,0/N), on applique de ce fait la règle 3 on prendra soin de renommer la clé étrangère pour conserver la sémantique du problème, sans oublier la donnée portée. STAGE(Numéro stage, Libellé stage, Date stage, Durée stage, Numéro formateur responsable#, Prime) FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur) Solution 2 : On considère être en présence d’une association non hiérarchique (1/N,0/N) porteuse de données, on applique de ce fait la règle 4. STAGE(Numéro stage, Libellé stage, Date stage, Durée stage) FORMATEUR(Numéro formateur, Nom formateur, Prénom formateur) RESPONSABLE(Numéro stage#, Numéro formateur#, Prime)

La sémantique du modèle nous indique qu’un étudiant peut ou ne pas être délégué de classe, et qu’une classe peut compte de 0 à 2 délégué. ETUDIANT(Code élève, nom, prénom) CLASSE(Code classe, effectif) DELEGUE(Code classe#, Code élève#) On peut aussi imaginer la solution suivante ETUDIANT(Code élève, nom, prénom) CLASSE(Code classe, effectif, Code délégué1#, Code délégué2#) Identifiant relatif

HOTEL(Référence hotel, Nom hotel, Adresse hotel) CHAMBRE(Référence hotel#, Numéro chambre, Nombre place, Surface)

BATIMENT(N°Batiment)  il est important de conserver la relation BATIMENT ETAGE(N°Batiment#, N°Etage) SALLE((N°Batiment#, N°Etage)#, N°Salle, Nbplace) Cas particulier

CLASSE(Code classe, Libellé classe, Effectif) MATIERE(Code matière, Libellé matière) 25/49

PROFESSEUR(Numéro professeur, Nom professeur, Prénom professeur) ASSURE_les_COURS(Code classe#, Code matière#, Numéro professeur#)

26/49

Modélisation des traitements Introduction: Les programmes les plus fréquemment développés sont ceux utilisant une interface utilisateur permettant de travailler sur un ensemble de données, par exemple les clients d'une entreprise. Il faut pouvoir ajouter, supprimer, modifier les clients, en afficher la liste. Une base de données permet de stocker les données. Il y a quelques années, dans l'interface utilisateur, du code lisait, modifiait la base de données. Très vite, sur un projet important cette approche, non architecturée, montrait ses limites. Aussi très rapidement, en programmation fonctionnelle, le besoin de travailler sur des couches est apparu: Pour afficher la liste des client de l'entreprise: La couche présentation: une windowsForm affichait la liste ; elle faisait appel à: La couche métier: une routine ChargeListe située dans un module standard sélectionnait les clients, elle faisait appel à: La couche données qui lisait la base de données. Cela a été formalisé en programmation objet. A noté que si les divers couches sont sur les ordinateurs différents, on parle d'architecture distribuée.

Architecture n-tiers De l'anglais tier signifiant étage ou niveau. Architecture logicielle impliquant plusieurs composants, chaque composant étant le client d’un et le serveur d’un autre. Le cas le plus simple de ce type d’architecture est le modèle Client/Serveur qui est en 2-tiers.

Tier 'Client' – Contient l’interface utilisateur, adresse des requêtes au serveur. Tier 'Serveur' - Contient la base de données. Reçoit les requêtes, renvoie des données. Dans les modèles 3-tiers et plus, il existe des composants intermédiaires qu’on appelle également middleware. Un exemple typique d’un système 3-tier est le suivant :

27/49

• Tier de présentation – c’est principalement l’interface utilisateur. contient les différents types de clients, léger (Web, ASP, JSP) ou lourd (Swing, WinForm) • Tier des règles de gestion: couche métier: (Business Logic. ) • Tier de base de données – les programmes du deuxième tier font appel à ce dernier pour consulter ou mettre à jour les données relatives à l’entreprise. Sur le même schéma, on peut ajouter des intermédiaires supplémentaires et obtenir une architecture 4, 5, …, n-tier.

Architecture 3 tiers: L'architecture 3-tier (de l'anglais tier signifiant étage ou niveau) vise à séparer très nettement trois couches logicielles au sein d'une même application ou système, à modéliser et présenter cette application comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini : la présentation des données : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur, le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des règles de gestion et de la logique applicative, c’est à ce niveau que se trouvent toutes les règles de gestion, et toute l’intelligence de la démarche. et enfin l' accès aux données persistantes (persistancy en anglais) : correspondant aux données qui sont destinées à être conservées sur la durée. Relation entre les couches: Les services d'une couche sont mis à disposition de la couche supérieure. On s'interdit par conséquent qu'une couche invoque les services d'une couche plus basse que la couche immédiatement inférieure ou plus haute que la couche immédiatement supérieure (chaque niveau ne communique qu'avec ses voisins immédiats). Voir les flèches sur le schéma suivant:

28/49

Exemple 1:Ma bibliothèque (En écrivant du code VB.NET) Créons une application permettant de saisir, d'enregistrer, de voir des fiches 'Livre':

Il faut créer des objets 'Livre' puis un objet 'Livres' contenant une collection de tous les livres (Couche métier). Cette collection doit pouvoir être enregistrée puis lue sur disque (Couche d'accès au données). Enfin on doit pouvoir afficher le détail d'un livre (Interface utilisateur).

Couche métier : Classe « ClasseLivre » : entité métier, classe permettant d'instancier un livre avec comme propriété : Titre, auteur.. Classe « ClasseLivres » (avec un 's'): classe comprenant une collection d’objet « Livre ». Elle possède des méthodes permettant d'ajouter un livre, de récupérer un livre dans la collection, de passer au précédent, au suivant...

Couche d’accès aux données : LoadData pour lire la collection de livres à partir d'un fichier (xml dans notre exemple) SaveData pour enregistrer la collection de livres dans un fichier (xml dans notre exemple)

29/49

Interfaces graphiques : 1 Formulaire principal permettant de saisir un nouveau livre et de faire défiler les livres. A - Couche métier: Créons la ClasseLivre", elle doit contenir: 2 property public : 'Titre' et 'Auteur' 2 variables private : m_titre et m_Auteur Cela permettra d'instancier un objet livre et d'utiliser ses propriétés: Exemple: Dim livre As New ClasseLivre : livre.Nom= "Cours VB" Voici la classe: Public Class ClasseLivre Private m_Titre As String Private m_Auteur As String ' Propriété Titre Public Property Titre() As String Get Return m_Titre End Get Set(ByVal value As String) m_Titre = value End Set End Property ' Propriété Auteur Public Property Auteur() As String Get Return m_Auteur End Get Set(ByVal value As String) m_Auteur = value End Set End Property End Class

Créons la ClasseLivres" (avec un 's'), elle doit contenir: 1 collection nommée ListLivre d'objet génériques: Collection.Generic.List (Of Classelivre) C'est une collection typée, elle ne peut contenir que des 'Livre' On instancie aussi un objet ad d'accès aux données. La méthode public LivrePointé retourne le livre en cours, les méthodes FirstLivre, LastLivre, NextLivre, PreviousLivre permettent de se déplacer dans les livres. On peut ajouter un livre avec AddLivre. Une variable nommée m_numéro sert dans la classe de "pointeur" du livre courant. Pour enregistrer ou charger la collection de livre sur disque, il y a les 2 méthodes SaveData et LoadData. Elle appelle des méthodes de la couche de données. Quand cette classe est instanciée elle charge les données (la procédure New appelle LoadData). 30/49

Imports System.Collections.Generic Public Class ClasseLivres Private ListLivre As New List(Of ClasseLivre) 'Collection de Livre Private m_numero As Integer Private ad As New AccesAuxDonnees 'Constructeur, charge la collection Public Sub New() Me.LoadData() End Sub Public Sub LoadData() ad.LoadData(ListLivre) m_numero = 0 End Sub Public Sub SaveData() ad.SaveData(ListLivre) End Sub 'Retourne le livre courant Public Function LivrePointé() As ClasseLivre If ListLivre.Count <> 0 Then If m_numero < ListLivre.Count Then Return ListLivre.Item(m_numero) Else Return Nothing End If Else Return Nothing End If End Function 'Ajouter un livre Public Sub AddLivre(ByVal l As ClasseLivre) ListLivre.Add(l) End Sub 'Effacer le livre courant Public Sub RemoveLivre() ListLivre.RemoveAt(m_numero) End Sub 'Mettre à jour un livre Public Sub UpdateLivre(ByVal l As ClasseLivre) ListLivre.Item(m_numero) = l End Sub 'Livre suivant Public Sub NextLivre()

31/49

If m_numero < ListLivre.Count Then m_numero += 1 End If End Sub 'Livre précédent Public Sub PreviousLivre() If m_numero > 0 Then m_numero -= 1 End If End Sub 'Premier Livre Public Sub FirstLivre() m_numero = 0 End Sub 'Dernier livre Public Sub LastLivre() m_numero = ListLivre.Count - 1 End Sub End Class

Il aurait été plus élégant d'instancier l'objet d'accès au données dès le début de la classe comme cela: Public Class ClasseLivres Private ListLivre As New List(Of ClasseLivre) 'Collection de Livre Private m_numero As Integer Dim ad As New AccesAuxDonnees

B - Couche d'accès aux données: Ici nous enregistrons les données dans un fichier XML nommé "Meslivres.Xml" (il sera dans le répertoire bin/Debug lors de la conception, et dans le répertoire de l'exécutable si on installe le logiciel). On utilise la sérialisation et les Stream. Les Sub ont un paramètre: la collection de ClasseLivre.Ce paramètre est passé avec ByRef . Imports System.Xml.Serialization Imports System.IO Public Class AccesAuxDonnees Public Sub SaveData(ByVal list As Collections.Generic.List(Of ClasseLivre)) ' Déclaration Dim serialXML As Xml.Serialization.XmlSerializer = Nothing Dim streamIO As StreamWriter = Nothing Try

32/49

serialXML = New Xml.Serialization.XmlSerializer(GetType(Collections.Generic.List(Of ClasseLivre))) ' Ouverture d'un flux en écriture sur le fichier XML streamIO = New StreamWriter("Meslivres.Xml") ' Sérialisation de la liste des contacts serialXML.Serialize(streamIO, list) Catch ex As Exception ' Propager l'exception Throw ex Finally ' En cas d'erreur, n'oublier pas de fermer le flux en écriture si ce dernier est toujours ouvert If streamIO IsNot Nothing Then streamIO.Close() End If End Try End Sub Public Sub LoadData(ByRef list As Collections.Generic.List(Of ClasseLivre)) ' Déclaration Dim streamIO As StreamReader = Nothing Dim serialXML As Xml.Serialization.XmlSerializer = Nothing Try ' Tester l'existance du fichier If System.IO.File.Exists("Meslivres.Xml") = True Then serialXML = New Xml.Serialization.XmlSerializer(GetType(Collections.Generic.List(Of ClasseLivre))) ' Ouverture d'un flux en lecture sur le fichier XML des contacts streamIO = New StreamReader("Meslivres.Xml") ' Désérialisation de la liste list = CType(serialXML.Deserialize(streamIO), Collections.Generic.List(Of ClasseLivre)) End If Catch ex As Exception ' Propager l'exception Throw ex Finally ' En cas d'erreur, n'oublier pas de fermer le flux en lecture si ce dernier est toujours ouvert If streamIO IsNot Nothing Then streamIO.Close() End If End Try End Sub End Class

C - Couche de présentation: interface graphique

33/49

On instancie un objet Livres, cet objet contient la collection de livre. Il suffit ensuite d'utiliser Livres.LivrePointé qui est le livre en cours, Livres.NextLivre() pour passer au livre suivant, Livres.PreviousLivre pour passer au précédent. Quand on clique sur 'Enregister livre' on effectue Livres.AddLivre. Quand on clique sur 'Enregister tous les livres' on effectue Livres.SaveData ( qui fait appel à la couche de données). Deux petites Sub LireLivre et AfficheLivre permettent de remplir ou de lire les TextBox à partir d'un objet livre. Public Class InterfaceGraphique Dim Livres As New ClasseLivres Dim iFlagNewLivre As Integer Sub LireLivre(ByVal l As ClasseLivre) l.Titre = TextBoxTitre.Text l.Auteur = TextBoxAuteur.Text End Sub Sub AfficheLivre(ByVal l As ClasseLivre) If l IsNot Nothing Then TextBoxTitre.Text = l.Titre TextBoxAuteur.Text = l.Auteur End If End Sub Private Sub ButtonNext_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ButtonNext.Click Livres.NextLivre() AfficheLivre(Livres.LivrePointé) iFlagNewLivre = False End Sub

34/49

Private Sub ButtonPrevious_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles ButtonPrevious.Click Livres.PreviousLivre() AfficheLivre(Livres.LivrePointé) iFlagNewLivre = False End Sub Private Sub ButtonNew_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ButtonNew.Click TextBoxTitre.Text = "" TextBoxAuteur.Text = "" iFlagNewLivre = True End Sub Private Sub ButtonEnregister_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ButtonEnregister.Click Dim NouveauLivre As New ClasseLivre If iFlagNewLivre = True Then LireLivre(NouveauLivre) Livres.AddLivre(NouveauLivre) Livres.LastLivre() Else LireLivre(NouveauLivre) Livres.UpdateLivre(NouveauLivre) End If iFlagNewLivre = False End Sub Private Sub ButtonEnregistertous_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ButtonEnregistertous.Click Livres.SaveData() End Sub End Class

Exemple 2: Ma bibliothèque (Avec un BindingSource et génération automatique de l'IU)(VB 2005) C'est le même programme, mais on va laisser le soin à VB de générer automatiquement l'interface utilisateur et les liens (Binding) entre cette interface et les données. La couche d'accès aux données est la même. On a une Form vide. A - Couche métier:

ClasseLivre est identique, par contre ClassesLivres est plus simple: elle contient uniquement la collection généric ListLivre contenant les livres (Et SaveData et Load Data)

Imports System.Collections.Generic

35/49

Public Class ClasseLivre Private m_Titre As String Private m_Auteur As String ' Propriétés Titre Public Property Titre() As String Get Return m_Titre End Get Set(ByVal value As String) m_Titre = value End Set End Property ' Propriétés Auteur Public Property Auteur() As String Get Return m_Auteur End Get Set(ByVal value As String) m_Auteur = value End Set End Property Public Function GetTitre() As String Return m_Titre End Function End Class Public Class ClasseLivres Public ListLivre As New Collections.Generic.List(Of ClasseLivre) Private ad As New AccesAuxDonnees Public Sub LoadData() ad.LoadData(ListLivre) End Sub Public Sub SaveData() ad.SaveData(ListLivre) End Sub End Class

Ici ListLivre est Public. B - Création de la source de données: Il faut ensuite créer une source de données: Comme on affiche des livres, la source c'est la ClasseLivre.

36/49

Menu 'Données'=> 'Ajouter une nouvelle source de données'

Ici la source de données n'est pas une base de données mais un Objet: On clique sur 'Objet' puis bouton 'Suivant'.

37/49

On déroule livre, qui est le nom de la solution, puis on clique sur 'ClasseLivre' et sur le bouton suivant. Puis Ok; la source de données est créée. C - Génération automatique de l'interface utilisateur: Visual Studio dispose d'une fenêtre 'Sources de données' depuis laquelle vous pouvez faire glisser des éléments jusqu'à un formulaire pour créer automatiquement des contrôles liés aux données qui affichent des données. Afficher les sources de données: Menu 'Données' puis 'Afficher les sources de données'

Il apparaît à droite la fenêtre 'Sources de données' Dérouler 'livre' et cliquer sur 'ClasseLivre' Pour générer, non par une grid mais des zones de saisie, dérouler la liste de ClasseLivre et cliquer sur 'Détails'. Enfin faire un drag ans drop à partir de ClasseLivre et déposer le sur la form de gauche (qui est vide au départ)

38/49

Miracle: il apparaît automatiquement: -des zones textbox pour chaque properties de la classe avec un label devant. -une barre de navigation (tout est généré automatiquement: les bitmap des boutons dans les ressources Setting...) -Un composant BindingSource.(Il fait le lien entre l'interface et la source de données) -Un composant BindingNavigator.(Il gère la barre de navigation)

On voit bien en dessous les 2 composants qui ont été ajoutés. D - Création du Binding: Maintenant ,il faut indiquer la source de données, le Datasource du BindingSource: c'est la collection MesLivres.ListLivre (C'est pour cela que la collection ListLivre est Public) Public Class Form1 Dim MesLivres As New ClasseLivres Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load ClasseLivreBindingSource.DataSource = MesLivres.ListLivre End Sub 'On peut ajouter dans la form 2 boutons permettant la sauvegarde ou la lecture sur disque. Private Sub SauveLivres_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click MesLivres.SaveData() End Sub Private Sub LoadLivre_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click MesLivres.LoadData()

39/49

ClasseLivreBindingSource.DataSource = MesLivres.ListLivre End Sub End Class

Ici, les différentes parties du logiciel sont dans la même solution. Rien n'empêche de:  Mettre les classes dans un même fichier .vb  Mettre les classes dans différents fichiers .vb  Créer les Classes dans une solution, la générer, inclure dans les références du projet principal les dll.  Enfin si diverses parties sont sur différentes machines, on parle d'architecture distribuée.

40/49

EXEMPLE DE PROJET GESTION D'UNE MÉDIATHÈQUE MUNICIPALE Afin de pourvoir ses habitants d'une vie culturelle locale, une municipalité souhaite se doter d'une médiathèque moderne. Elle lance un appel d'offres pour la réalisation du logiciel de gestion de la médiathèque. Le village dispose actuellement d'une bibliothèque dont le fonds de 2000 ouvrages est géré manuellement par une bibliothécaire. Grâce au bibliobus du conseil général et par un système de prêt inter bibliothèques, elle peut avoir accès à des ouvrages qu'elle ne possède pas. Le village voisin, possède un vidéo club très actif géré par une association loi 1901, celui-ci a connu un tel engouement que la gestion par des bénévoles n'est plus possible. L'association est prête à céder son stock de cassettes vidéo (environ 1000) et le logiciel mis en place pour gérer le prêt. Il est souhaitable de réutiliser ce logiciel et de l'étendre si possible à la gestion des livres. A terme, la municipalité entend constituer un stock de CD audio et DVD. Le prêt se fera au moyen d'une carte magnétique attribuée à chaque adhérent contre une caution. L'adhésion est gratuite, une cotisation annuelle variable selon le lieu de résidence et l'âge de l'adhérent sera également demandée. La commande de nouveaux livres se fait actuellement auprès des représentants des maisons d'édition qui passent régulièrement ; le maire souhaiterait éventuellement le faire par Internet (via bol.fr ou la fnac par exemple ou directement par l'éditeur si possible). En ce qui concerne la commande de nouvelles cassettes, l'association faisait jusqu'ici son choix dans un catalogue disponible sous diverses formes : papier, disquette ou en ligne (via Internet). On souhaite traiter les commandes informatiquement et intégrer à terme la comptabilité de la médiathèque dans la comptabilité globale de la municipalité.

41/49

VERSION PRÉCISE DU CAHIER DES CHARGES RÉDIGÉ APRÈS UNE SÉANCE D'INTERVIEWS ET ENTRETIEN TÉLÉPHONIQUE AVEC LE CLIENT Ce document sera signé par le client, il fait partie du contrat

Objet: Informatisation de la gestion d'une médiathèque.

.1

Inscription d'un adhérent

.1

Lors de l'inscription d'un adhérent, le gestionnaire entre dans le système les coordonnées de l'adhérent et la date d'adhésion. Le client reçoit une carte magnétique qui servira d'identification . En cas de perte de la carte, le système devra pouvoir identifier le client par son nom, prénom et date de naissance.

.2

L'adhérent dépose une somme variable qui servira à la fois de caution (en cas de perte) et de cotisation annuelle, cette somme alimente le compte du client.

.3

Le montant de l'adhésion est fonction de l'âge et du lieu de résidence de l'adhérent.

.2

Emprunts de cassettes

.1

Pour que l'emprunt soit réalisable l'emprunteur doit être adhérent (posséder une carte d'adhérent) sinon le gestionnaire enregistre l'adhésion.

.2

L'adhérent donne au gestionnaire sa carte de membre.

.3

Pour que l'emprunt soit réalisable, le compte du client doit être à jour de sa cotisation annuelle.

.4

L'adhérent demande au gestionnaire le titre de son choix ou cherche dans un catalogue la cassette qu'il souhaite emprunter. Il peut également demander à emprunter le dernier film de tel réalisateur ou un film dont il connaît le titre…. Le système indique s'il reste une cassette disponible du film choisi

.5

S'il existe une cassette disponible du film demandé et que le compte du client est suffisamment approvisionné, alors l'emprunt devient effectif, il est enregistré dans le système. L'exemplaire est scanné grâce a une douchette optique qui enregistre le numéro de l'article, le numéro de l'adhérent ayant été détecté par le lecteur de cartes ou retrouvé le cas échéant grâce à son identité.

.6

La durée des emprunts est variable mais ne peut dépasser 3 jours. Pas de renouvellement possible sans interruption pour une même cassette.

42/49

.7

On ne peut emprunter plus de deux cassettes à la fois

.8

Si le film souhaité n'est pas disponible, le client peut le réserver. Il sera prévenu par courrier de la disponibilité. La réservation sera maintenue pendant dix jours après la date de mise à disposition de l'exemplaire.

.9

Si le film souhaité n'a pas été acheté par le vidéo club, le gestionnaire peut décider de l'acheter ou bien simplement enregistrer l'information concernant les goûts des adhérents.

.3

Emprunt de livres

.1

L'adhérent donne au gestionnaire sa carte de membre

.2

Pour que l'emprunt soit réalisable, le compte du client doit être à jour de sa cotisation annuelle

.3

L'adhérent dépose sur le comptoir le livre qu'il a choisi sur les étagères ou cherche dans le catalogue de la bibliothèque municipale , ou dans le catalogue inter bibliothèques (imprimé par le gestionnaire à partir d'Internet) le titre à emprunter .

.4

On ne peut emprunter plus de 4 livres à la fois.

.5

S'il existe un exemplaire disponible du livre demandé et que le compte du client est suffisamment approvisionné, alors l'emprunt devient effectif, il est enregistré dans le système. L'exemplaire est scanné grâce a une douchette optique qui enregistre le numéro de l'exemplaire, le numéro de l'adhérent ayant été détecté par le lecteur de cartes ou retrouvé le cas échéant grâce à son identité

.6

La durée d'un emprunt ne peut dépasser 10 jours, il peut être renouvelé une fois.

.7

Si le livre souhaité n'est pas disponible, le client peut le réserver. Il sera prévenu par courrier de la disponibilité. La réservation sera maintenue pendant dix jours après la date de mise à disposition de l'exemplaire.

.8

En ce qui concerne le prêt inter bibliothèques, du point de vue du logiciel, la demande de l'adhérent équivaut à une réservation, il faut en outre que le gestionnaire commande le livre par Internet.

.4

Retour d'une cassette ou d'un livre

.1

Lorsque le client retourne sa cassette ou son livre ils sont remis dans le stock sauf s'il s'agit d'un exemplaire correspondant à un livre ou un film réservé par un adhérent.

.2

Dans ce dernier cas, l'exemplaire retourné est mis de côté, l'adhérent est prévenu par courrier de la disponibilité de sa réservation. La réservation est maintenue dix jours après la date de disponibilité.

43/49

.3

Si l'adhérent est en retard, il doit payer une pénalité proportionnelle au nombre de jours de retard.

.4

Il serait opportun de comptabiliser le nombre d'emprunts de chaque cassette de manière à les remplacer si elles ont trop servi.

.5

Périodiquement le système relance les adhérents retardataires

.6

Au bout d'un certain temps un livre ou une cassette peut être considéré comme perdu

.5

Gestion des commandes de cassettes ou de livres

.1

Le gestionnaire reçoit périodiquement des catalogues. Le gestionnaire choisit les éléments à commander parmi les catalogues reçus

.2

Le gestionnaire tient compte des goûts des adhérents, des succès en salle, des indications de la critique.

.3

Le système édite automatiquement une ligne de commande correspondant au choix du gestionnaire, le système regroupe toutes les lignes de commandes concernant un fournisseur pour rédiger un bon de commande par fournisseur.

.6

Gestion des livraisons de cassettes ou de livres

.1

Lors de la livraison d'une cassette, le gestionnaire enregistre la cassette ou le livre dans le stock.

.2

A l'avenir, on peut imaginer qu'un courrier sera adressé régulièrement aux adhérents pour leur signaler les nouveautés.

.7

Contraintes de réalisation

.1

La municipalité a commandé un PC équipé d'un modem sous Windows médiathèque

.2

Elle a souscrit un abonnement Internet auprès de wanadoo

.3

Le PC sera installé dans les jours qui viennent dans la salle réservée à la médiathèque

.4

Les catalogues de prêt interbibliohèque sont disponibles sur le web

.5

Le PC est équipé du logiciel de gestion de bases de données Access.

.6

Le logiciel devra fonctionner avec une interface graphique à base de boutons, menus souris.

.7

Le logiciel existant n'est pas réutilisable en l'état.

44/49

pour la

.8

.8 .1

.9

La gestion des cartes d'adhérents nécessite l'acquisition d'un lecteur de cartes, BB SA est chargé du choix de l'appareil, mais non de son achat.

Limites Le logiciel ne gérera pas la comptabilité dans un premier temps.

Evolutions prévues

.1

Mise en ligne des catalogues sur le web

.2

Installation d'un réseau de consultation à l'intérieur de la médiathèque

.3

Extension à la gestion de DVD et de CD audio

.4

Gestion de la comptabilité

45/49

Les fonctionnalités du système sont résumées dans les cas d'utilisation ci-dessous (notation UML) MEDIATHEQUE

Administrer

Fournisseur

Lecteur-optique

Gestionnaire

Adherent On note adhérent mais en fait l'adhérent n'intervient dans le système qu'au travers du lecteur de carte magnétique

Gérer_emprunts

46/49

Internet_réseau_ bibliothèques

CAS D'UTILISATION : Gérer emprunts

Gérer_emprunts < >

Gestionnaire

<> Adhérent

(from Use Case View)

(from Use Case View)

Verifier_adherent

>

vérifier dans la base de données adhérents

Gérer_adhérent

Retour_emprunts

Verifier_dispo <> <>

Enregistrer_emprunt

mettre à jour la base de données emprunts stocks adhérents

Réserver Vérifier_dispo_film Vérifier_dispo_livre

vérifier dans la base de données stocks

<>

vérifier dans la base de données stocks

mettre à jour la base de données stocks

Mémoriser_gouts mettre à jour la base de données gouts

Emprunt_internet

mettre à jour la base de données emprunts interbibli

Gérer_réservations

<>

Internet_réseau_ bibliothèques (from Use Case View)

47/49

mettre à jour la base de données emprunts stocks adhérents

CAS D'UTILISATION : Administrer

Gestionnaire (from Use Case View)

Administrer < < > >

alimente la base de données adhérents consulte la BD tarifs

Gérer_adhérent Gérer_stock <>

<> < > < < >

>

<> Gérer_rappels Inscrire_adhérent

consulte la base de données emprunts

Enregistrer_cotisation_annuelle

Gérer_pertes Gérer_RB

Gérer_commandes

consulte la base de données emprunts RB

consulte la base de données emprunts

<>

<<extends>> met à jour la base de données adhérents

met à jour la base de données adhérents

Fait à

Statistiques_gouts utilise la base de données gouts

<>

Enregistrer_Livraisons Editer_commandes

utilise la base de données fournisseurs met a jour la BD stock

met à jour la base de données stocks consulte

le

Pour BB Sa Bill Boss

pour la municipalité

48/49

49/49