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 DIRECTRICE CDC TERTIAIRE & TIC

M. ESSABKI NOURDDINE 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 sous-
processus 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, Numéro client#)

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)

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 pour la
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
.8 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.

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

.9 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 Gérer_emprunts
l'adhérent Internet_réseau_
n'intervient bibliothèques
dans le
système
qu'au travers
du lecteur de
carte
magnétique

46/49
 CAS D'UTILISATION : Gérer emprunts

Gérer_emprunts
<<include>
> <<include>>
Gestionnaire Adhérent
(from Use Case View) (from Use Case View)

Verifier_adherent
<include>>
vérifier dans
la base de Verifier_dispo Retour_emprunts Gérer_réservations
données
<<include>>
adhérents
Gérer_adhérent
<<include>> mettre à jour la
base de données
<<include>> emprunts
stocks
Enregistrer_emprunt
adhérents
Réserver

Vérifier_dispo_film
mettre à jour
la base de mettre à jour la
vérifier dans Vérifier_dispo_livre Mémoriser_gouts données base de
la base de stocks données
données emprunts
stocks <<include>> mettre à
jour la stocks
base de adhérents
données
gouts
vérifier dans
la base de
données Emprunt_internet
stocks

mettre à
jour la
base de Internet_réseau_
données bibliothèques
emprunts (from Use Case View)
interbibli

47/49
 CAS D'UTILISATION : Administrer

Gestionnaire
(from Use Case View) Administrer

<<include>
> <<include>
alimente la base de >
données
adhérents
consulte la BD tarifs
Gérer_adhérent Gérer_stock

<<include>> <<include> <<include>>

<<include>> <<include>
> >
<<include>>

Gérer_rappels Gérer_pertes Gérer_RB

Gérer_commandes
Inscrire_adhérent consulte la consulte la
consulte la base de
base de base de
données données
données emprunts RB
emprunts emprunts <<include>>
Enregistrer_cotisation_annuelle
<<include>>
<<extends>>
met à jour la
base de
données
adhérents met à jour la Enregistrer_Livraisons
base de Editer_commandes
données Statistiques_gouts
adhérents met à
utilise la utilise la
base de jour la
base de base de
données données
gouts données
fournisseurs stocks
met a jour la consulte
BD stock

Fait à le

Pour BB Sa pour la municipalité

Bill Boss

48/49
49/49