Chapitre 13
Description of Systems
Lecture : 26 minQuiz de 12 questions
# Description of Systems
## Objectifs et prérequis
**Objectifs** : À l’issue de ce chapitre, l’élève sera capable de :
- Définir un système et identifier ses composantes essentielles.
- Classer les systèmes selon leurs caractéristiques (ouverts/fermés, naturels/artificiels, statiques/dynamiques).
- Expliquer le rôle et les éléments d’un diagramme de flux de données (DFD).
- Construire un DFD de niveau 0 (contexte) et de niveau 1 à partir d’une description verbale d’un système d’information.
- Interpréter un DFD existant pour identifier les entrées, sorties, processus et réserves de données.
- Appliquer ces concepts à des systèmes d’information camerounais et africains pertinents.
- Préparer une réponse structurée à une question d’examen sur la modélisation par DFD.
**Prérequis** : Notions de base en traitement de l’information, familiarité avec l’usage des ordinateurs et des logiciels courants (traitement de texte, tableur), capacité à lire et interpréter des schémas simples.
---
## Introduction
Dans le domaine des Technologies de l’Information et de la Communication (TIC), comprendre ce qu’est un système et comment le modéliser est fondamental pour analyser, concevoir ou améliorer des solutions informatiques. Un système d’information, par exemple, n’est pas seulement un ordinateur ou un logiciel : c’est un ensemble organisé d’éléments (humains, matériels, logiciels, données, procédures) qui travaillent ensemble pour atteindre un objectif spécifique, comme la gestion des notes scolaires dans un lycée camerounais ou le suivi des vaccinations dans un centre de santé régional. Ce chapitre introduit d’abord la théorie générale des systèmes, puis se concentre sur un outil de modélisation clé : le diagramme de flux de données (DFD). Ce dernier permet de représenter visuellement comment les données circulent dans un système, quels processus les transforment et où elles sont stockées. La maîtrise du DFD est essentielle pour les élèves de Lower Sixth, car elle constitue une base pour l’analyse des systèmes d’information, une compétence évaluée aux examens du GCE Advanced Level et pertinente pour des carrières en informatique, gestion ou ingénierie des systèmes.
---
## I. Types of Systems
### Contexte
L’étude des systèmes fournit un cadre conceptuel pour comprendre comment les éléments interagissent dans des domaines variés : biologie, ingénierie, gestion, informatique. En TIC, cette approche permet d’éviter une vision trop centrée sur la technologie seule et de considérer les aspects humains, organisationnels et environnementaux. Le programme camerounais insiste sur la capacité à distinguer différents types de systèmes afin de choisir des méthodes d’analyse et de conception appropriées.
### Définitions et caractéristiques essentielles
> **Un système est un ensemble d’éléments interagissants organisés selon des règles pour atteindre un objectif commun.**
Cette définition souligne trois aspects : l’ensemble (pas juste une collection aléatoire), l’interaction (les éléments s’influencent mutuellement) et l’objectif (finalité qui donne du sens à l’organisation).
Un système possède :
- **Des entrées (inputs)** : énergie, matière, information provenant de l’environnement.
- **Des sorties (outputs)** : résultats produits par le système destinés à l’environnement.
- **Un processus** : transformation interne des entrées en sorties.
- **Un environnement** : tout ce qui se trouve en dehors du système mais qui peut l’influencer ou être influencé par lui.
- **Une frontière** : limite conceptuelle séparant le système de son environnement.
- **Un objectif (ou finalité)** : but que le système cherche à atteindre.
### Classification des systèmes
Les systèmes peuvent être classés selon plusieurs critères pertinents en TIC :
1. **Selon l’interaction avec l’environnement :**
- **Système ouvert** : Échange librement de l’énergie, de la matière ou de l’information avec son environnement. *Exemple* : Un système de gestion scolaire (comme celui utilisé au Lycée Bilingue de Yaoundé) reçoit des entrées (inscriptions nouvelles, notes des enseignants, directives du MINEDUB) et produit des sorties (bulletins, statistiques d’effectifs, rapports pour le ministère). Il est ouvert car il dépend fortement de son environnement.
- **Système fermé** : Échange négligeable ou nul avec l’environnement. *Exemple théorique* : Une calculatrice autonome fonctionnant sur pile, isolée du réseau, effectuant seulement des calculs internes. En pratique, peu de systèmes TIC sont totalement fermés aujourd’hui à cause du besoin de mises à jour ou d’échange de données.
- **Système isolé** : Idéalisation où aucun échange n’a lieu (souvent utilisé en physique théorique). Rarement pertinent en TIC appliquée.
2. **Selon l’origine :**
- **Système naturel** : Existe indépendamment de l’intervention humaine (ex. : système solaire, écosystème de la forêt du Cameroun, système circulatoire humain).
- **Système artificiel** : Créé ou modifié délibérément par l’homme pour un but spécifique. *Exemples TIC* : Un système de réservation de billets pour Cameroon Airlines, un système de paie pour la fonction publique camerounaise, un réseau mobile MTN ou Orange Cameroun.
3. **Selon la stabilité du comportement :**
- **Système statique** : Sa structure et ses relations restent constantes dans le temps (pas de changement interne significatif pendant l’observation). *Exemple* : Un tableau de conversion fixe (français vers anglais) utilisé dans un manuel scolaire.
- **Système dynamique** : Sa structure, ses relations ou son état évoluent dans le temps. *Exemple* : Un système de gestion des stocks dans une pharmacie régionale (comme à l’Hôpital Régional de Douala) où les niveaux de stock changent constamment selon les livraisons et les délivrances.
4. **Selon la déterminisme :**
- **Système déterministe** : Pour un même ensemble d’entrées, les sorties sont toujours prévisibles et identiques. *Exemple* : Un programme informatique qui calcule la moyenne pondérée selon une formule fixe.
- **Système probabiliste (ou stochastique)** : Le même ensemble d’entrées peut produire différentes sorties selon des probabilités. *Exemple* : Un système de prévision de la demande électrique pour ENEO qui intègre l’incertitude liée au temps.
### Causes et conséquences de la classification
Comprendre ces classifications a des implications pratiques :
- Un **système ouvert** nécessite une analyse approfondie de ses interfaces avec l’environnement (ex. : comment le système scolaire camerounais intègre-t-il les réformes du MINEDUB ?).
- Un **système artificiel** implique des choix de conception délibérés (langage de programmation, architecture réseau) qui peuvent être évalués et améliorés.
- Un **système dynamique** nécessite des mécanismes de mise à jour et de suivi (ex. : sauvegardes régulières, journaux d’activité).
- Confondre un système déterministe avec un probabiliste peut mener à des modèles irréalistes (ex. : supposer que la consommation d’eau dans un quartier de Yaoundé est parfaitement prévisible sans tenir compte des pluies ou des pannes).
### Vocabulaire à retenir
- Système, Entrée (Input), Sortie (Output), Processus, Environnement, Frontière, Objectif
- Système ouvert / fermé / isolé
- Système naturel / artificiel
- Système statique / dynamique
- Système déterministe / probabiliste
### Exemple de sujet type examen avec plan
**Sujet** : Expliquez la différence entre un système ouvert et un système fermé. Donnez un exemple concret de chacun, tiré du contexte camerounais ou africain, en justifiant votre choix.
**Plan proposé** :
1. **Définition générale d’un système** (rappel bref des composantes : entrées, sorties, processus, environnement, frontière, objectif).
2. **Caractéristiques du système ouvert** : Échange significatif avec l’environnement. Conséquence : dépendance et sensibilité aux changements externes.
3. **Exemple camerounais d’un système ouvert** : Le système de gestion des dossiers patients dans un centre de santé intégré (CSI) comme celui de Nkoldongo (Yaoundé). *Justification* : Entrées = nouveaux patients, résultats de laboratoire, prescriptions ; Sorties = dossiers mis à jour, statistiques de morbidité, factures ; Environnement = MINSANTE, laboratoires externes, pharmacies, patients eux-mêmes. Le système doit s’adapter aux normes du MINSANTE et aux flux de patients.
4. **Caractéristiques du système fermé** : Échange négligeable avec l’environnement. Conséquence : autonomie relative mais risque d’obsolescence.
5. **Exemple africain d’un système fermé (ou approximativement fermé)** : Un distributeur automatique de billets (DAB) autonome installé dans une zone rurale avec peu de connectivité (ex. : certaines régions du Nord-Cameroun ou du Tchad voisin), fonctionnant uniquement avec une carte préchargée et ne communiquant pas en temps réel avec la banque centrale. *Justification* : Entrées = carte et code PIN ; Sorties = argent liquide ; Peu ou pas d’échange continu d’informations de compte avec l’environnement bancaire pendant l’opération de retrait (les mises à jour se font par lots plus tard). *Note* : Préciser que c’est une approximation, car même ces DAB nécessitent parfois une synchronisation périodique.
6. **Synthèse** : L’ouverture/fermeture dépend du degré d’interaction nécessaire au fonctionnement et aux objectifs du système. En TIC, la plupart des systèmes d’information sont intentionnellement ouverts pour être utiles et réactifs.
---
## II. Modelling a System with a Data Flow Diagram
### Contexte
Alors que la leçon précédente fournit le cadre conceptuel (« qu’est-ce qu’un système ? »), cette leçon introduit un outil pratique pour représenter un type spécifique de système : le **système d’information**. Un système d’information traite des données pour produire de l’information utile. Pour analyser, concevoir ou communiquer sur la structure d’un tel système, les informaticiens utilisent des modèles graphiques. Le **Diagramme de Flux de Données (DFD)**, développé dans les années 1970 dans le cadre de l’analyse structurée (notamment par Yourdon et De Marco), est l’un des plus anciens et des plus utilisés pour modéliser la logique fonctionnelle d’un système du point de vue des données. Il montre *comment* les données se déplacent, où elles sont stockées et quelles transformations leur sont appliquées, sans préciser *comment* ces transformations sont implémentées techniquement (langage, matériel). Cela en fait un outil précieux dans les premières étapes de l’analyse des systèmes, conforme à l’approche pédagogique du programme camerounais qui vise à développer des compétences d’analyse avant la programmation pure.
### Définitions et éléments fondamentaux d’un DFD
> **Un Diagramme de Flux de Données (DFD) est un modèle graphique qui représente le flux des données à travers un système, montrant d’où viennent les données, comment elles sont transformées par des processus, où elles sont stockées et où elles vont.**
Il se concentre exclusivement sur le *quoi* (les données et leur mouvement), pas sur le *comment* (les détails d’implémentation).
Les quatre symboles fondamentaux d’un DFD (notation Yourdon/De Marco ou Gane/Sarson) sont :
1. **Entité externe (External Entity)** : Représente une personne, un organisation ou un autre système qui interagit avec le système modélisé, mais qui fait partie de son environnement. Elle fournit des entrées au système ou reçoit des sorties. *Notation* : Rectangle contenant le nom de l’entité (ex. : « Étudiant », « Enseignant », « MINEDUB »).
2. **Processus (Process)** : Représente une activité qui transforme, manipule, ou route des données d’entrée en données de sortie. Il doit avoir au moins une entrée et une sortie de données. *Notation* : Cercle ou rectangle arrondi contenant un numéro et une description verbe-nom (ex. : « 1. Calculer la Moyenne », « 2. Vérifier l’Inscription »).
3. **Réserve de données (Data Store)** : Représente un endroit où les données sont stockées pour une utilisation ultérieure. Les données peuvent être lues (entrée vers le réserve) ou écrites (sortie du réserve). *Notation* : Deux lignes parallèles (ou un rectangle ouvert côté droit) contenant le nom de la réserve (ex. : « Dossiers Étudiants », « Fichier Notes »).
4. **Flux de données (Data Flow)** : Représente le mouvement des données d’un point à un autre dans le système. Il montre ce qui est échangé, pas comment. *Notation* : Flèche dirigée portant un nom décrivant le contenu des données (ex. : « Formulaire d’Inscription », « Bulletin Scolaire », « Demande de Vérification »).
### Règles et principes de construction
> **Un DFD doit être équilibré** : Les entrées et sorties de données d’un processus de niveau inférieur doivent correspondre exactement aux entrées et sorties du processus qu’il détaillent au niveau supérieur.
> **Un processus doit avoir au moins une entrée et une sortie de données** : Un processus sans entrée ne fait rien ; un processus sans sortie est inutile (sauf peut-être pour afficher, mais l’affichage est une sortie vers une entité externe comme un utilisateur).
> **Une réserve de données doit être reliée à au moins un processus** : Elle ne peut pas être directement connectée à une entité externe ou à une autre réserve (l’accès aux données doit passer par un processus).
> **Les flux de données ne peuvent pas aller directement d’une entité externe à une autre entité externe** : Toute interaction entre l’environnement doit être médiée par au moins un processus du système.
> **Chaque flux de données doit avoir un nom significatif** décrivant le *type* de données échangées (éviter des noms vagues comme « données » ou « info »).
### Niveaux de DFD
La modélisation par DFD se fait généralement par **décomposition successive** (top-down) :
- **DFD de niveau 0 (ou Diagramme de Contexte)** : Montre le système d’information entier comme un **seul processus** (souvent numéroté 0). Il entoure ce processus par toutes les **entités externes** qui interagissent avec lui et les **flux de données** principaux entrant et sortant. Il ne montre *aucune* réserve de données ni détail interne. Son but est de définir clairement la frontière du système et son interaction avec l’environnement.
- **DFD de niveau 1** : Détaille le processus unique du niveau 0 en le décomposant en ses **processus majeurs** (généralement entre 2 et 7). Il montre comment ces processus interagissent entre eux via des réserves de données et des flux, tout en conservant les mêmes entités externes et les mêmes flux de données principaux entrant/sortant que le niveau 0 (principe d’équilibre). Il peut montrer des réserves de données.
- **DFD de niveau 2, 3, etc.** : Détaille davantage un processus spécifique du niveau 1 (ou supérieur) en montrant ses sous-processus internes. Moins fréquemment requis aux examens de Lower Sixth, mais le principe est le même.
### Exemple concret : Système de gestion des inscriptions au Lycée Bilingue de Yaoundé
*Contexte* : Le lycée souhaite modéliser son processus d’inscription annuelle pour les nouvelles élèves de Seconde.
1. **DFD de Niveau 0 (Contexte)** :
- *Processus central (0)* : Système d’Inscription du Lycée Bilingue de Yaoundé.
- *Entités externes* :
- Nouvelle Élève (et ses parents/tuteurs)
- Service Scolarité du Lycée (personnel administratif)
- MINEDUB (Délégation Régionale du Centre - pour les effectifs et les normes)
- Service Comptabilité du Lycée (pour les frais de scolarité)
- *Flux de données principaux* :
- De Nouvelle Élève vers 0 : « Formulaire d’Inscription Complété » (avec pièces jointes : acte de naissance, relevé de notes, certificat de médical)
- De 0 vers Nouvelle Élève : « Confirmation d’Inscription » ou « Notification de Refus / Liste d’Attente »
- De Service Scolarité vers 0 : « Liste d’Attente Approuvée » (en cas de besoin), « Directives d’Inscription » (procédures internes)
- De 0 vers Service Scolarité : « Liste des Nouveaux Inscrits », « Statistiques d’Entrée »
- De MINEDUB vers 0 : « Normes d’Effectifs par Classe », « Calendrier Scolaire Officiel »
- De 0 vers MINEDUB : « Rapport d’Effectifs Préliminaire », « Rapport d’Effectifs Définitif »
- De Service Comptabilité vers 0 : « État des Paiements Effectués » (pour vérifier qui a payé)
- De 0 vers Service Comptabilité : « Liste des Élèves à Facturer », « Détails des Frais Dus »
> *À retenir* : Le DFD de niveau 0 définit la frontière du système. Ici, le système d’inscription interagit avec l’élève, la scolarité, le MINEDUB et la comptabilité. Il ne montre pas *comment* l’inscription est traitée en interne.
2. **DFD de Niveau 1** (Décomposition du processus 0) :
- On décompose le processus 0 en sous-processus majeurs. Une décomposition logique pourrait être :
- **Processus 1.0** : Vérifier la Complétude et la Conformité du Dossier
- **Processus 2.0** : Vérifier la Disponibilité de Place selon les Normes du MINEDUB
- **Processus 3.0** : Enregistrer l’Inscription et Générer les Documents
- **Processus 4.0** : Gérer le Paiement des Frais de Scolarité (si applicable à ce stade ou lié)
- *Entités externes* : Identiques au niveau 0 (Nouvelle Élève, Service Scolarité, MINEDUB, Service Comptabilité).
- *Réserves de données potentielles* :
- `Dossiers Temporaires` : Stocke les formulaires reçus en attente de vérification (lié aux processus 1.0 et 2.0).
- `Fichier Élèves Inscrits` : Stocke les données définitives des élèves admis (lié aux processus 3.0 et 4.0, et lu par le processus 0 pour les sorties vers Scolarité/MINEDUB).
- `Fichier Places Disponibles` : Stocke le nombre de places restantes par classe et série (mis à jour par le processus 2.0, lu par le processus 2.0).
- `Fichier Paiements` : Stocke les enregistrements de paiement (lié aux processus 4.0 et lu par le processus 0 pour la sortie vers Comptabilité).
- *Flux de données internes* (exemples) :
- De Nouvelle Élève vers 1.0 : « Formulaire d’Inscription Complété »
- De 1.0 vers `Dossiers Temporaires` : « Dossier Réceptionné » (ou le formulaire lui-même stocké)
- De `Dossiers Temporaires` vers 1.0 : « Données du Dossier » (pour vérification)
- De 1.0 vers 2.0 : « Résultat Vérification Dossier » (Conforme / Non Conforme)
- De MINEDUB vers 2.0 : « Normes d’Effectifs », « Effectifs Actuels par Classe » (peut venir d’une réserve ou directement)
- De `Fichier Places Disponibles` vers 2.0 : « Places Disponibles Actuelles »
- De 2.0 vers `Fichier Places Disponibles` : « Mise à Jour Places » (après attribution)
- De 2.0 vers 3.0 : « Autorisation d’Inscription » (si dossier conforme ET place disponible)
- De 3.0 vers `Fichier Élèves Inscrits` : « Nouvel Enregistrement Élève »
- De `Fichier Élèves Inscrits` vers 3.0 : « Données Élève Existantes » (pour éviter doublons ou mise à jour)
- De 3.0 vers Nouvelle Élève : « Confirmation d’Inscription »
- De 3.0 vers Nouvelle Élève : « Notification de Refus » (si pas de place malgré dossier conforme) - *Alternativement géré par 2.0*
- De Service Scolarité vers 1.0 ou 2.0 : « Procédures Vérification » (directives internes)
- De 3.0 vers Service Scolarité : « Liste des Nouveaux Inscrits » (générée à partir du fichier élèves inscrits)
- De 3.0 vers Service Comptabilité : « Détails des Frais Dus » (basés sur la série/inscription)
- De Service Comptabilité vers 4.0 : « État des Paiements » (pour vérification)
- De 4.0 vers `Fichier Paiements` : « Enregistrement Paiement »
- De `Fichier Paiements` vers 4.0 : « Statut Paiement Élève »
- De 4.0 vers Nouvelle Élève : « Reçu de Paiement »
- De 4.0 vers Service Comptabilité : « Rapport de Paiements Journaliers »
- De `Fichier Élèves Inscrits` vers 0 : « Statistiques d’Entrée » (pour sortie vers Scolarité/MINEDUB)
- De `Fichier Élèves Inscrits` vers 0 : « Rapport d’Effectifs » (pour sortie vers MINEDUB)
- De Service Comptabilité vers 0 : « État des Paiements Effectués » (pour sortie vers Comptabilité - *Note* : ce flux pourrait aussi venir directement du fichier paiements via un processus dédié, mais pour simplifier le niveau 0, on le montre venant de l’entité si l’entité fournit l’état).
> *À retenir* : Le DFD de niveau 1 montre le détail interne tout en conservant les mêmes entrées/sorties globales que le niveau 0 (équilibre). Chaque processus transforme des données, les réserves stockent des informations intermédiaires ou définitives.
### Bonnes pratiques et erreurs courantes
- **Nommez les processus avec un verbe d’action suivi d’un nom** (ex. : « Valider l’Inscription », « Générer le Bulletin »). Évitez les noms vagues comme « Traitement » ou « Gestion ».
- **Nommez les réserves de données avec un nom au pluriel ou collectif** représentant ce qui est stocké (ex. : « Dossiers Étudiants », « Fichier Notes », « Registre Paiements »). Évitez les noms comme « Fichier1 » ou « Temp ».
- **Nommez les flux de données clairement** pour indiquer *quoi* est transféré (ex. : « Demande de Vérification d’Identité », « Résultat du Test d’Aptitude »). Évitez les flèches sans nom ou des noms comme « données ».
- **Respectez l’équilibre** : Si un processus de niveau 1 a une entrée « Formulaire d’Inscription » venant de l’entité « Nouvelle Élève », alors le processus 0 du niveau 0 doit avoir exactement cette même entrée venant de cette même entité. De même pour les sorties.
- **Ne connectez jamais une réserve directement à une entité externe** : Pour qu’une entité lise ou écrive dans une réserve, il doit y avoir un processus intermédiaire (ex. : l’entité « Enseignant » ne lit pas directement « Fichier Notes » ; il y a un processus « Saisir les Notes » qui écrit dans la réserve, et un processus « Consulter les Notes » qui lit depuis la réserve vers l’entité).
- **Limitez le nombre de processus au niveau 1** : Idéalement entre 3 et 7 pour garder la lisibilité. Plus de 7 suggère qu’une décomposition supplémentaire (niveau 2) pourrait être utile ou que le niveau 1 est trop détaillé.
### Vocabulaire à retenir
- Diagramme de Flux de Données (DFD)
- Entité externe
- Processus
- Réserve de données (Data Store)
- Flux de données (Data Flow)
- Niveau 0 (Diagramme de Contexte)
- Niveau 1
- Équilibre (Balancing)
- Décomposition
- Notation Yourdon/De Marco (ou Gane/Sarson)
### Exemple de sujet type examen avec plan
**Sujet** : Décrivez les étapes pour construire un DFD de niveau 1 à partir d’une description verbale d’un système d’information. Illustrez votre réponse en prenant comme exemple le système de gestion des prêts de livres dans une bibliothèque scolaire camerounaise (comme celle du Lycée Général Leclerc de Yaoundé).
**Plan proposé** :
1. **Rappel des principes du DFD** : Définir brièvement ce qu’est un DFD et son objectif (modéliser le flux des données, pas l’implémentation). Mentionner les 4 symboles de base.
2. **Étape 1 : Identifier les entités externes** : Lire la description pour trouver qui interagit avec le système depuis l’extérieur. *Exemple bibliothèque* : Élève, Enseignant, Bibliothécaire (souvent considéré comme partie du système, mais si son rôle est juste d’utiliser l’interface, il peut être une entité externe ; ici, on le considère souvent comme faisant partie du système car il effectue les processus, donc les entités externes sont principalement Élève et Enseignant. *Attention* : cela dépend de la définition du système. Si le système est « l’application de gestion de bibliothèque », alors le bibliothécaire est une entité externe. Si le système est « le processus de prêt incluant l’humain », alors le bibliothécaire est interne. Pour un DFD classique en analyse de systèmes, on modélise le système informatisé, donc le bibliothécaire utilisant le logiciel est une entité externe. On précisera : *Supposons que le système modélisé est l’application informatique de gestion des prêts*. Entités externes : Élève, Enseignant, Bibliothécaire (en tant qu’utilisateur du logiciel).)
3. **Étape 2 : Identifier les flux de données principaux entrant et sortant** : Trouver quelles données entrent dans le système depuis chaque entité externe et quelles données en sortent vers chaque entité externe. *Exemple* :
- Entrant depuis Élève : « Demande de Prêt » (avec ID élève et ID livre), « Retour de Livre » (avec ID livre).
- Sortant vers Élève : « Confirmation de Prêt », « Rappel de Retour », « Reçu de Retour ».
- Entrant depuis Enseignant : Peut-être « Demande de Prêt Spécial » (si règles différentes) ou souvent rien de spécifique si traité comme élève. On peut simplifier : Enseignant agit comme un élève pour ce système. Ou bien, si distinct : « Demande de Prêt (Enseignant) », sortant : « Confirmation de Prêt (Enseignant) ».
- Entrant depuis Bibliothécaire : « Instructions de Configuration » (rare pour le niveau 1, plus pour config), mais principalement, le bibliothécaire *initie* des actions via l’interface, donc ses entrées/sorties sont les mêmes qu’un élève/enseignant utilisant le système. Pour éviter la confusion, on se concentre souvent sur les flux liés aux actions principales : Le bibliothécaire peut entrer des corrections manuelles (« Correction d’Erreur de Retour »), mais au niveau 1, on se focalise sur les flux métiers principaux. On dira : Les flux liés aux interactions humaines (élève, enseignant, bibliothécaire utilisant le système) sont souvent similaires. Pour simplifier l’examen, on peut considérer que les entités externes sont Élève et Bibliothécaire (si le bibliothécaire gère les exceptions), ou juste Élève si le système est entièrement en libre-service (moins courant au Cameroun). *Choix pédagogique clair* : Entités externes : **Élève**, **Bibliothécaire** (représentant le personnel qui gère le système et traite les cas particuliers comme les retards ou les pertes). Flux :
- Élève → Système : « Demande de Prêt », « Retour de Livre »
- Système → Élève : « Confirmation de Prêt », « Rappel de Retour », « Reçu de Retour »
- Bibliothécaire → Système : « Signalement de Livre Perdu/Endommagé », « Mise à Jour Statut Livre » (après vérification physique)
- Système → Bibliothécaire : « Liste des Retards », « Alertes de Livre Manquant », « Rapport d’Activité »
4. **Étape 3 : Définir le processus unique du niveau 0** : Nommer le système d’information global. *Exemple* : « Système de Gestion des Prêts de Bibliothèque » (processus 0).
5. **Étape 4 : Décomposer le processus 0 en processus majeurs pour le niveau 1** : Identifier les activités principales qui transforment les données. *Exemple bibliothèque* :
- **Processus 1.0** : Traiter la Demande de Prêt
- **Processus 2.0** : Gérer le Retour de Livre
- **Processus 3.0** : Gérer les Retards et les Pertes
- (On pourrait avoir un processus 4.0 pour la gestion du catalogue, mais si on se concentre sur les prêts/retours, 3 processus suffisent).
6. **Étape 5 : Identifier les réserves de données nécessaires** : Déterminer où les données doivent être stockées pour être utilisées par différents processus. *Exemple* :
- `Fichier Élèves` : Contient les données des élèves (ID, nom, classe, statut). Lu par 1.0 (vérifier éligibilité), 2.0 (mettre à jour l’historique de prêt), 3.0 (envoyer rappel). Écrit par un processus d’inscription scolaire (hors périmètre, donc juste lu ici).
- `Fichier Livres` : Contient les données des livres (ID, titre, auteur, statut disponible/prêté/perdu, localisation). Lu par 1.0 (vérifier disponibilité), 2.0 (mettre à jour statut à « disponible »), 3.0 (marquer comme perdu/endommagé). Écrit par 1.0 (statut à « prêté »), 2.0 (statut à « disponible »), 3.0 (statut à « perdu/endommagé »).
- `Fichier Prêts Actifs` : Contient les enregistrements des prêts en cours (ID prêt, ID élève, ID livre, date de prêt, date de retour prévue). Lu par 2.0 (trouver le prêt correspondant au retour), 3.0 (identifier les prêts en retard). Écrit par 1.0 (nouvel enregistrement de prêt), effacé ou archivé par 2.0 (après retour réussi).
- `Fichier Retards` : Contient les prêts en retard (ID prêt, ID élève, ID livre, jours de retard). Lu par 3.0 (générer rappels), écrit par 3.0 (mise à jour du statut de retard), lu par un processus de génération de rapports (hors périmètre niveau 1).
7. **Étape 6 : Dessiner les flux de données entre les éléments** : Connecter les entités externes aux processus, les processus aux réserves, et les réserves aux processus, en respectant l’équilibre avec le niveau 0. *Exemple de flux clés* :
- Élève → 1.0 : « Demande de Prêt » (ID Élève, ID Livre)
- 1.0 → `Fichier Élèves` : « Requête Vérification Élève » (ou simplement lit les données)
- `Fichier Élèves` → 1.0 : « Données Élève » (pour vérification)
- 1.0 → `Fichier Livres` : « Requête Vérification Livre »
- `Fichier Livres` → 1.0 : « Données Livre » (statut, titre)
- 1.0 → `Fichier Livres` : « Mise à Jour Statut Livre » (à « Prêté »)
- 1.0 → `Fichier Prêts Actifs` : « Nouvel Enregistrement de Prêt »
- 1.0 → Élève : « Confirmation de Prêt » (ID Livre, Date de Retour Prévue)
- Élève → 2.0 : « Retour de Livre » (ID Livre)
- 2.0 → `Fichier Prêts Actifs` : « Requête Recherche Prêt » (par ID Livre)
- `Fichier Prêts Actifs` → 2.0 : « Détails du Prêt Actif » (ID Élève, Date Prévue)
- 2.0 → `Fichier Prêts Actifs` : « Suppression Enregistrement Prêt » (ou archivage)
- 2.0 → `Fichier Livres` : « Mise à Jour Statut Livre » (à « Disponible »)
- 2.0 → Élève : « Reçu de Retour »
- 2.0 → `Fichier Prêts Actifs` : « Requête Recherche Prêts en Retard » (pour 3.0, ou 3.0 lit directement)
- `Fichier Prêts Actifs` → 3.0 : « Liste des Prêts en Retard Potentiels » (ou 3.0 calcule à partir des dates)
- 3.0 → `Fichier Retards` : « Nouvel Enregistrement de Retard »
- 3.0 → `Fichier Retards` : « Mise à Jour Enregistrement de Retard » (augmenter jours)
- 3.0 → `Fichier Livres` : « Mise à Jour Statut Livre » (à « Perdu » ou « Endommagé »)
- 3.0 → Bibliothécaire : « Signalement de Livre Perdu » (entrée depuis bibliothécaire pour déclencher 3.0)
- Bibliothécaire → 3.0 : « Confirmation de Perte/Dommage » (après vérification)
- 3.0 → Bibliothécaire : « Liste des Retards à Traiter », « Alertes de Livres Perdus »
- (Vérifier l’équilibre : Les entrées/sorties globales du niveau 1 doivent matcher celles définies pour le niveau 0 à l’étape 2).
8. **Étape 7 : Vérifier l’équilibre et la lisibilité** : S’assurer que chaque processus a au moins une entrée et une sortie, que les réserves ne sont connectées qu’à des processus, que les noms sont clairs, et que le nombre de processus au niveau 1 est raisonnable (3-7 ici).
9. **Conclusion** : Résumer que le DFD de niveau 1 fournit une vue détaillée mais toujours abstraite du fonctionnement logique du système d’information, montrant comment les données circulent entre les acteurs externes, les processus de traitement et les réserves de stockage, sans préciser la technologie utilisée.
---
## Synthèse du chapitre
- Un système est un ensemble d’éléments interagissants avec un objectif, des entrées, des sorties, des processus, un environnement et une frontière.
- Les systèmes se classent selon leur ouverture (ouvert/fermé/isolé), leur origine (naturel/artificiel), leur dynamique (statique/dynamique) et leur déterminisme (déterministe/probabiliste).
- Comprendre ces classifications aide à analyser la dépendance à l’environnement, la nature des choix de conception et le comportement prévisible d’un système.
- Un Diagramme de Flux de Données (DFD) modélise le flux logique des données dans un système d’information, en se concentrant sur le *quoi* (données, transformations, stockage) et non sur le *comment* (implémentation technique).
- Les quatre symboles fondamentaux du DFD sont : entité externe, processus, réserve de données et flux de données.
- Un DFD est construit par niveaux : niveau 0 (contexte, montrant le système comme un seul processus et ses interactions avec l’environnement) et niveau 1 (décomposant le processus du niveau 0 en processus majeurs, montrant les réserves et les flux internes, tout en maintenant l’équilibre avec le niveau 0).
- La construction d’un DFD suit des règles strictes : équilibre, chaque processus doit avoir entrée et sortie, les réserves ne connectent qu’à des processus, pas de flux direct entité externe → entité externe, noms significatifs.
- L’application à des systèmes camerounais et africains (gestion scolaire, santé, bibliothèque, prêts) permet de contextualiser les concepts abstraits et de montrer leur pertinence pour l’analyse des systèmes d’information réels.
- La maîtrise du DFD développe des compétences d’analyse essentielles pour la conception et l’évaluation des systèmes d’information, pertinentes pour les examens du GCE A-Level et les carrières en TIC.
---
Quiz du chapitre
12 questions — vérifie chaque réponse pour voir l'explication.