Université de Cergy-Pontoise

RAPPORT

pour le projet Génie Logiciel

Licence d’Informatique deuxième année

sur le sujet

OS
rédigé par

Esanu Iulian, Cozma Miroslav, Nkounkou Christy

Avril 2020
Table des matières
1 Introduction 4
1.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Organisation du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Spécification du projet 5
2.1 Pilotes et périphériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Attribution des identificatifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Interface de Programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Noyau : Fonctionnement et Rôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Description Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Méthodes Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Langage Interprété . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4 Évolutivité du Noyeau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Gestion des Processus : Simulation de l’Exécution Concurrente . . . . . . . . . . . . . 6
2.3.1 Description Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Description Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Disques durs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Conception et réalisation du projet 8

3.1 Conception des classes de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Liste des classes de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Conception du Noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Le noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 TaskMgmt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3 FileExe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Conception de l’IHM graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Mode de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Mode task manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3 Mode Text Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Tests du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1 Tests Unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2 Tests de Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3 Tests de Robustesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.4 Tests d’Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Système de journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1 Journal de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.2 Structuration du journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Instrumentation dulogiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Manuel utilisateur 16

5 Déroulement du projet 17
5.1 Réalisation du projet par étapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Répartition des tâches entre membres de l’équipe . . . . . . . . . . . . . . . . . . . . . 17

6 Conclusion et perspectives 18
6.1 Résumé du travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Améliorations possibles du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1
Table des figures
1 IHM Graphique - Mode de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 IHM Graphique - Mode Task Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 IHM Graphique - Mode Text Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Liste des tableaux

2
Remerciements
Les auteurs du projet voudraient remercier vivement...

3
1 Introduction
Intéréssons nous à notre projet de génie logiciel, qui aura pour but de simuler le comportement
d’un mini-système d’exploitation, de ses périphériques et de ses applications. Plus précisément, chaque
périphérique sera associé à un pilote défini par un numéro unique. Ces pilotes permettront au noyau
d’interagir avec les périphériques en utilisant des primitives. Par exemple, la commande ’ioctl’ posi-
tionnera l’emplacement du disque où lire ou écrire. Nous émulerons le comportement de divers périphé-
riques, tels que le clavier, la souris, le microphone, l’écran, l’imprimante, le haut-parleur et le disque
dur. Certains n’autoriseront uniquement la lecture (le système pourra lire les signaux envoyés par ces
périphériques), tandis que d’autres uniquement l’écriture (le système ne pourra qu’envoyer des signaux
vers ces périphériques). Le disque dur, quant à lui, permettra à la fois la lecture et l’écriture. Notre
système prendra en charge la gestion concurrente des processus. Lors du lancement d’une application,
un processus sera créé, comportant les instructions données par le langage. Ces processus seront exé-
cutés de manière concurrentielle par le système, qui gérera plusieurs processus simultanés. Le système
donnera l’illusion de traiter plusieurs processus “en même temps” en utilisant l’approche “round-robin”
pour répartir équitablement le temps d’exécution entre les processus.

1.1 Contexte du projet

Ceci est une démonstration d’un document rédigé en utilisant LaTex.

Attention ! ! Dans cette démonstration, il y a des éléments qui doivent se trouver dans
votre rapport final du projet Génie Logiciel, ce sont surtout les sections et les sous-sections
(sous-sous-sections parfois) et les éléments au début : page de garde, table des matières
etc., et la bibliographies à la fin.

Les autres éléments sont là juste pour illustrer le fonctionnement de Latex.

1.2 Objectif du projet

1.3 Organisation du rapport

4
2 Spécification du projet
Nous avons présenté l’objectif du projet dans la section 1. Dans cette section, nous présentons la
spécification de notre logiciel réalisé. Ceci correspond principalement au document de spécification du
projet (cahier des charges).

2.1 Pilotes et périphériques

Le produit final doit être capable de simuler le fonctionnement des périphériques de base d’un
ordinateur. Ces différents périphériques doivent être simulés dans leurs fonctionnements, et ceci grâce à
des pilotes (simulés eux aussi). Chaque périphérique aura un pilote associé et doit pouvoir interagir avec
le noyau de l’OS via son pilote grâce à des méthodes de lecture, d’écriture et de commandes. Aucune
méthode n’est obligatoire sur un périphérique, tout dépend des besoins spécifiques du périphérique en
question.

Les périphériques de base sont :

— Les périphériques d’entrée : Le pilote du périphérique n’a besoin que d’une méthode de lecture.
— Les périphériques de sortie : Le pilote du périphérique n’a besoin que d’une méthode d’écriture.
— Les périphériques d’entrée/sortie : Le pilote du périphérique a besoin d’une méthode d’écriture
et d’une méthode de lecture.

2.1.1 Attribution des identificatifiants

Les pilotes et périphériques seront identifiables par un numéro unique (id) attribué de manière
statique. Ils se verront assigné un identifiant fixe tout au long du fonctionnement du système. Cette
approche offre la stabilité des identifiants, facilitant ainsi la gestion et la compréhension du système.

2.1.2 Interface de Programmation

Une interface de programmation sera soigneusement élaborée pour garantir que les méthodes et les
commandes destinées aux pilotes et aux périphériques restent connues dans le temps. Cette interface
sera conçue de manière à faciliter l’ajout de nouveaux pilotes et périphériques sans nécessiter de
modifications majeures.

2.2 Noyau : Fonctionnement et Rôle

2.2.1 Description Générale
Le noyau représente le cœur même du système d’exploitation, assurant la cohésion et l’interaction
harmonieuse entre ses différentes composantes. Son rôle premier est de fournir des méthodes primitives
essentielles, constituant le socle du bon fonctionnement de l’OS. Ces primitives sont responsables de
diverses manipulations, telles que la gestion des fichiers, la création et le contrôle des processus, la ges-
tion de la mémoire, la communication interprocessus, la synchronisation, le contrôle des périphériques,
ainsi que la manipulation des fichiers et des répertoires.

2.2.2 Méthodes Primitives

1. Création de Processus :
— fork : Crée un nouveau processus identique à celui qui l’appelle.
— exec : Charge un nouveau fichier binaire dans l’espace d’adressage d’un processus, rempla-
çant ainsi le fichier binaire en cours d’exécution.
2. Gestion des Fichiers :
— open, close : Ouvre et ferme des fichiers respectivement.
— read, write : Lit et écrit des données depuis et vers des fichiers.
3. Contrôle des Processus :

5
 — exit : Termine l’exécution d’un processus.
— wait : Attend la fin d’un processus.
— kill : Envoie un signal à un processus en suivant les conventions classiques.
4. Gestion de la Mémoire :
— brk, sbrk : Ajuste la taille du segment de données d’un processus.
— nmap, munmap : Gère la mémoire mappée.
5. Interprocessus :
— pipe : Crée un canal de communication entre deux processus.
— socket : Crée un point de communication pour les processus réseau (à ajuster en fonction
des besoins et de l’avancement du projet).
6. Synchronisation :
— semaphore : Permet la synchronisation entre processus.
— mutex : Utilisé pour la synchronisation entre threads (à adapter en fonction des besoins).
7. Contrôle des Périphériques :
— ioctl : Contrôle divers aspects des périphériques.
8. Gestion des Fichiers et des Répertoires :
— mkdir, rmdir : Crée et supprime des répertoires respectivement.
— unlink : Supprime un fichier.

2.2.3 Langage Interprété

L es différentes primitives seront regroupées dans un langage interprété, similaire à l’Assembly, per-
mettant la création de programmes de base incluant des structures de contrôle telles que boucles et
sauts.

2.2.4 Évolutivité du Noyeau

D ’autres primitives pourront être ajoutées au langage interprété en fonction des besoins futurs du
projet, garantissant ainsi une adaptabilité continue aux exigences en évolution du système d’exploita-
tion.

2.3 Gestion des Processus : Simulation de l’Exécution Concurrente

2.3.1 Description Générale
U n autre élément critique du noyau réside dans la gestion des processus, car l’OS doit être en mesure
d’exécuter plusieurs programmes simultanément, une tâche impossible d’un point de vue matériel. Pour
résoudre cette problématique, la simulation de l’exécution concurrente sera implémentée en utilisant la
méthode de planification Round Robin. Cette approche implique l’exécution séquentielle d’une opéra-
tion de chaque programme en cours d’exécution, suivie de la mise en pause de ce programme, avant de
passer au suivant. Cette séquence se répète cycliquement, créant ainsi une impression de simultanéité
grâce à la vitesse d’exécution du processeur.

2.3.2 Description Générale

F onctionnalités Requises :
— Planification Round Robin :
— Mise en œuvre d’une planification Round Robin pour simuler l’exécution concurrente des
programmes.
— Attribution d’un quantum de temps à chaque programme pour son exécution.
— Exécution Séquentielle :
— Chaque programme doit effectuer une opération à la fois pendant son quantum alloué.
— Mise en pause du programme après l’opération, suivi du passage au programme suivant.
— Changement de Contexte :

6
 — Implémentation d’un mécanisme de changement de contexte pour une transition fluide d’un
programme à un autre.
— Sauvegarde de l’état du programme en pause et restauration de l’état du programme suivant
lors du changement de contexte..
— Impression de Simultanéité :
— Malgré l’exécution séquentielle réelle, la simulation doit créer une impression de simultanéité
grâce à la rapidité d’exécution du processeur.
— Configurabilité du Quantum de Temps :
— Le quantum de temps alloué à chaque programme doit être configurable pour s’adapter aux
exigences spécifiques du système d’exploitation. Cette configuration aura une valeur par
défaut et pourra être modifiée grâce à une commande, ce qui permettra entre autres de
vérifier le bon fonctionnement du module Round Robin.

2.4 Disques durs

— Gestion des Disques Durs :
— Le noyau gère la simulation des disques durs dans le système, chaque disque étant identifié
par un numéro unique. Chaque disque dur sera en réalité simple fichier sur le pc de l’utili-
sateur Les données sont stockées dans des slots de taille fixe, accessibles via des commandes
ioctl dédiées.
— L’utilisateur de l’application pourra ajouter de nouveaux disques durs via des commandes,
il aura besoin de renseigner le nom du disque dur ainsi que sa taille (capacité de stockage).
Le numéro d’identification sera quant à lui attribué par l’OS.
— Commandes IOCTL pour les Disques Durs :
— Le noyau propose des commandes ioctl spécifiques pour les disques durs, permettant notam-
ment de spécifier l’emplacement du disque pour les opérations de lecture/écriture.
— Interaction avec les Applications :
— Les applications interagissent avec les disques durs simulés par le biais des primitives du
noyau, utilisant les méthodes standard de lecture (read) et écriture (write) pour accéder aux
données stockées.
— Gestion des Slots de Stockage :
— Les slots de stockage sur les disques durs simulés sont gérés efficacement par le noyau, avec
attribution et libération optimisées. Les applications travaillent directement avec ces slots,
conformément à l’absence de système de fichiers.
— Simplicité de Conception :
— La non-implémentation de systèmes de fichiers simplifie la conception du projet, influençant
la gestion des disques durs qui repose sur des slots numérotés. Cette simplicité facilite la
compréhension et l’efficacité de mise en œuvre.

7
3 Conception et réalisation du projet
Nous allons maintenant nous intéresser à l’aspect conception de notre projet

3.1 Conception des classes de données

3.1.1 Liste des classes de données
1. Classe Peripherique :
— Classe Abstraite.
— Attributs.
— String idPériphérique
2. Classe Clavier (Classe concrère, et fille de Classe Peripherique) :
— Classe Abstraite.
— Attributs.
— String idPériphérique
— Méthodes.
— ’read() ’ Lecture des données du périphérique.
3. Classe Souris (Classe concrète, et fille de Classe Peripherique) :
— Classe Abstraite.
— Attributs.
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle de la souris.
— Méthodes.
— read() : Lecture des données du périphérique.
4. Classe Micro (Classe concrète, et fille de Classe Peripherique) :
— Classe Abstraite.
— Attributs.
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle du microphone.
— Méthodes.
— read() : Lecture des données du périphérique.
5. Classe Ecran (Classe concrète, et fille de Classe Peripherique) :
— Classe Abstraite.
— Attributs.
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle de l’écran.
— Méthodes.
— write() : Écriture des données vers le périphérique.
6. Classe Souris (Classe concrète, et fille de Classe Peripherique) :
— Classe Abstraite.
— Attributs.
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle de la souris.
— Méthodes.
— read() : Lecture des données du périphérique.
7. Classe Micro (Classe concrète, et fille de Classe Peripherique) :
— Classe Abstraite.
— Attributs.
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle du microphone.
— Méthodes.
— read() : Lecture des données du périphérique.

8
 8. Classe Ecran (Classe concrète, et fille de Classe Peripherique) :
— Classe Abstraite.
— Attributs.
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle de l’écran.
— Méthodes.
— write() : Écriture des données vers le périphérique.
9. Classe Pilote :
— Attributs :
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle du pilote.
— Méthodes :
— envoyerCommande() : Envoie une commande au périphérique.
— recevoirDonnees() : Réceptionne les données du périphérique.
10. Classe Processus :
— Attributs :
— String ID
— String état
— List<String> Instructions
— LangageInterprete langage
— Méthodes :
— executer()
11. Classe Ordonnanceur :
— Attributs :
— List<Processus> Liste_processus
— int nb_processus
12. Gestionnaire Periphériques :
— Attributs :
— List<Peripherique> peripheriques
— List<Pilote> pilotes
— Méthode :
— ajouterPeripherique()
— lirePeripherique()
13. Classe Pilote :
— Attributs.
— String idPériphérique : Identifiant unique.
— Image Image : Représentation visuelle du pilote.
— Méthodes.
— envoyerCommande() : Envoie une commande au périphérique.
— recevoirDonnees() : Réceptionne les données du périphérique.
14. Classe Processus :
— Attributs.
— String ID : Identifiant du processus.
— String état : État du processus.
— List<String> Instructions : Liste des instructions du processus.
— LangageInterprete langage : Langage interprété par le processus.
— Méthodes.
— executer() : Exécute les instructions du processus.
15. Classe Ordonnanceur :
— Attributs.
— List<Processus> Liste_processus : Liste des processus.
— int nb_processus : Nombre de processus.

9
 16. Classe GestionnairePeripheriques :
— Attributs.
— List<Peripherique> peripheriques : Liste des périphériques.
— List<Pilote> pilotes : Liste des pilotes.
— Méthode.
— ajouterPeripherique() : Ajoute un périphérique.
— lirePeripherique() : Lit un périphérique.
17. Classe Application :
— Attributs.
— LangageInterprete langage : Langage interprété par l’application.
— String instructions : Instructions de l’application.
— Méthode.
— executer() : Exécute les instructions de l’application.

3.2 Conception du Noyau

3.2.1 Le noyau
Son rôle est de gérer/coordonner tous les éléments du système d’exploitation. Ce sera une sorte de
boucle qui s’assurera que chaque élément tourne comme il faut. Il s’occupera également de passer les
informations entre les différents périphériques/processus. Il est constitué de :
— Boolean run
— TaskMgmt
— FileExe
Une idée générale du code du noyau sera :
public void run() {
while (run) {
taskMgmt.check(); // ligne 1
fileExe.check(); // ligne 2
}
}

3.2.2 TaskMgmt
La partie données :
— TaskMgmt utilisera le Singleton Pattern pour stocker tous les processus en cours d’exécution
et s’assurer qu’il n’y ait qu’une seule instance. De cette manière, on peut gérer les conflits et
éventuels bugs dûs à la nature multi-threading du programme.

La partie traitement :
— Seuls les pilotes et les programmes codés dans le langage interprété du système sont concernés
par cette classe.
— Pour les pilotes, TaskMgmt vérifie s’il y a eu un changement dans le périphérique (ex : une
touche a été utilisée) et envoie l’information au noyau qui réagit en conséquence.
— Pour les processus qui utilisent le langage interprété du système, TaskMgmt s’occupe de frag-
menter et d’envoyer petit à petit les différentes opérations que font chaque processus (Round
Robin).

3.2.3 FileExe
FileExe s’occupera d’interpréter chaque petit bout de code qui a été transmis par TaskMgmt.
Comme son nom l’indique, ce sera une structure de données "file".
— Idées : Il faudra créer un "pipe" pour établir un moyen de communication entre deux pro-
cessus. Si le code en langage interprété lit une fonction CALL, il faut refaire l’ordre d’exécu-
tion/interprétation.

10
3.3 Conception de l’IHM graphique
Pour l’IHM graphique, nous avons voulu nous inspirer de l’invite de commandes (cmd) de notre cher
Windows. Plongeons maintenant dans les différents modes de notre IHM graphique

3.3.1 Mode de base

Figure 1 – IHM Graphique - Mode de base

Ce mode est le mode de base de notre IHM. On remarque la presence du chemin dans lequel l’uti-
lisateur se trouve actuellement. Ce dernier pourra y entrer des commandes, récupérer ses anciennes
commandes et les modifier en utilisant les flèches directionnelles. Il permettera aussi de créer des
périphériques, des processus, et de lancer un éditeur de texte pour coder ces processus.

3.3.2 Mode task manager

Figure 2 – IHM Graphique - Mode Task Manager

11
 Ce mode est le mode de gestion de notre IHM. Il est constitué de la liste des noms des processus,
de leur identifiants (ID), et potentiellement des valeurs RAM et CPU qui seront générés en fonction
de la complexité des programmes

3.3.3 Mode Text Editor

Ce mode est l’éditeur de texte de notre IHM. Il nous servira à écrire des scripts dans nos processus
avec notre langage interprété

Figure 3 – IHM Graphique - Mode Text Editor

3.4 Tests du logiciel

Les tests logiciels constituent une étape essentielle dans le développement de tout système informa-
tique. Ils consistent à vérifier et valider le bon fonctionnement d’un logiciel en évaluant son comporte-
ment par rapport aux spécifications prévues. Cette démarche vise à détecter les éventuelles erreurs, à
garantir la qualité du produit final et à assurer la satisfaction des utilisateurs.

3.4.1 Tests Unitaires

— Objectif: Vérifier le bon fonctionnement individuel de chaque composant logiciel, tel que les
pilotes de périphériques, les primitives du noyau, les processus, etc.
— Méthodologie: Écrire des tests automatisés pour chaque unité de code afin de valider son
comportement attendu dans différentes situations.
— Exemples:
— Pour les pilotes de périphériques, un test unitaire pourrait vérifier que la méthode de lecture
fonctionne correctement en simulant la lecture de données depuis un périphérique et en
comparant le résultat attendu avec celui renvoyé par la méthode.
— Pour les primitives du noyau, un test unitaire pourrait valider la création de processus en
vérifiant que l’appel à la fonction fork crée effectivement un nouveau processus avec le bon
contexte d’exécution.
— Pour les processus, un test unitaire pourrait s’assurer que la terminaison d’un processus à
l’aide de la fonction exit libère correctement les ressources associées et met à jour l’état du
système de manière appropriée.

12
3.4.2 Tests de Performance
— Objectif: Évaluer les performances globales du système, notamment en termes de temps de
réponse, de débit de lecture/écriture sur les périphériques, etc.
— Méthodologie: Effectuer des tests de charge pour mesurer la capacité du système à gérer un
grand nombre de processus simultanés ou à traiter des opérations intensives sur les périphé-
riques.
— Exemples:
— Un test de performance pourrait simuler une charge maximale sur le système en exécutant
un grand nombre de processus concurrents et en mesurant le temps nécessaire pour effectuer
des opérations courantes telles que la lecture/écriture sur les périphériques.
— Un test de performance pourrait évaluer la capacité du système à traiter de grandes quantités
de données en mesurant le débit de lecture/écriture sur un disque dur simulé avec différentes
tailles de fichiers.
— Un test de performance pourrait vérifier la réactivité du système en simulant des scénarios
d’utilisation intensive de l’IHM graphique et en mesurant le temps de réponse des interactions
utilisateur.

3.4.3 Tests de Robustesse

— Objectif: Tester la résilience du système face à des conditions anormales ou des entrées inat-
tendues, afin d’assurer sa stabilité et sa fiabilité
— Méthodologie: Injecter des données erronées ou simuler des pannes matérielles pour évaluer la
capacité du système à récupérer et à maintenir son bon fonctionnement.
— Exemples:
— Un test de robustesse pourrait simuler une panne de communication avec un périphérique en
envoyant des données corrompues et en vérifiant que le système détecte et gère correctement
cette situation anormale.
— Un test de robustesse pourrait évaluer la capacité du système à récupérer après un redé-
marrage inattendu en simulant une coupure de courant pendant une opération critique et
en vérifiant l’intégrité des données après le redémarrage.
— Un test de robustesse pourrait vérifier la tolérance aux erreurs de l’IHM graphique en simu-
lant des saisies incorrectes de l’utilisateur et en s’assurant que le système affiche des messages
d’erreur clairs et informatifs.

3.4.4 Tests d’Utilisation

— Objectif: Évaluer l’expérience utilisateur et la convivialité de l’IHM graphique en simulant les
interactions courantes avec le système.
— Méthodologie: Effectuer des scénarios d’utilisation typiques pour vérifier la facilité de naviga-
tion, la clarté des messages d’erreur et la cohérence de l’interface utilisateur.
— Exemples:
— Effectuer un scénario complet d’ajout et de suppression de fichiers via l’IHM graphique pour
vérifier la simplicité et l’efficacité du processus.
— Tester la navigation entre différentes fenêtres de l’IHM en simulant des clics sur les boutons
de navigation et en vérifiant que les transitions se déroulent sans problème.
— Évaluer la convivialité de l’IHM en demandant à des utilisateurs de réaliser des tâches
courantes, puis en recueillant leurs commentaires et leurs impressions sur l’expérience utili-
sateur.

3.5 Système de journal

Nous allons maintenant nous orienter vers le système de journal, qui est essentiel pour consigner les
événements importants lors de l’exécution d’un logiciel, facilitant ainsi le débogage, la traçabilité des
actions et la récupération après une panne.

13
3.5.1 Journal de sauvegarde
Les informations intéressantes à sauvegarder sous forme de journal dans notre logiciel pourraient
inclure :
— Les événements majeurs du système :
— Le démarrage et l’arrêt du système d’exploitation.
— Les actions effectuées par l’utilisateur :
— Les entrées dans le terminal de commande.
— L’initialisation d’un périphérique.
— La création d’un processus.
— L’utilisation de méthodes par les périphériques.
— La création ou la suppression de fichiers, etc.
— Les erreurs et les avertissements rencontrés pendant l’exécution du système :
— Des erreurs d’accès disque.
— Des échecs de création de processus, etc.
— L’ordonnancement des processus :
— Peut également servir à prouver que l’approche de planification Round Robin fonctionne
comme prévu.
— En examinant les logs, les développeurs peuvent vérifier si les processus sont effectivement
exécutés séquentiellement, avec une répartition équitable du temps CPU entre eux. Cela
permet de valider le bon fonctionnement de l’algorithme de planification et de s’assurer
qu’il respecte les spécifications du système en termes de gestion concurrente des processus.

3.5.2 Structuration du journal

Pour organiser efficacement les informations de journal, nous pourrions adopter un format standar-
disé comprenant plusieurs champs essentiels :
1. Classification Temporelle :
— Un timestamp, indiquant la date et l’heure précises de chaque événement, permettrait une
référence temporelle claire pour analyser les séquences d’événements et leur corrélation dans
le système. Alternativement, une numérotation séquentielle des actions pourrait également
être envisagée pour faciliter le suivi des événements dans l’ordre chronologique.
2. Type d’Événement :
— La catégorisation des événements en différents types tels que démarrage, arrêt, action utilisa-
teur, erreur, etc., serait cruciale pour comprendre rapidement la nature de chaque événement.
Cette classification faciliterait également le filtrage et la recherche des journaux en fonction
des types d’événements spécifiques.
3. Description :
— Une description détaillée de chaque événement fournirait des informations essentielles pour
comprendre pleinement son contexte. Cette description pourrait inclure des détails tels que
la ligne de commande entrée, le type de périphérique créé, le chemin du fichier créé ou
supprimé, le message d’erreur rencontré, etc. Ces informations seraient précieuses pour le
diagnostic et la résolution des problèmes rencontrés.

En adoptant cette approche structurée, nous pourrions créer des journaux systématiques et cohérents,
facilitant ainsi l’analyse, le dépannage et la surveillance du système d’exploitation. De plus, l’utilisation
de formats standardisés garantirait une interprétation uniforme des journaux par les différents outils
et analystes.

3.6 Instrumentation dulogiciel

Nous nous intéresserons ici à quelles sont les informations à afficher sur IHM graphique avant, pendant
et après le déroulement de notre logiciel, afin de garantir une bonne qualité d’instrumentation.
1. Avant le Déroulement :

14
 (a) Configuration Initiale : Affichage des paramètres de configuration du système, tels que
la taille du quantum de temps pour la planification des processus, la capacité de stockage
des disques durs simulés, etc. (forme : numérique)
(b) Liste des Périphériques : Affichage des différents périphériques émulés par le système,
y compris leur numéro d’identification et leur type (entrée, sortie, entrée/sortie). (forme :
numérique)
2. Pendant le Déroulement :
(a) Activité des Processus : Affichage en temps réel d’une liste des processus en cours d’exé-
cution, avec des informations telles que leur identifiant, leur état (en cours, en attente,
terminé), la quantité de temps CPU qu’ils ont consommée et éventuellement d’autres détails
pertinents. Cette liste peut être mise à jour dynamiquement pour refléter les changements
dans l’état des processus. (forme : numérique/textuelle)
(b) Utilisation des Périphériques : Affichage en temps réel de l’utilisation des différents
périphériques du système. Cela pourrait inclure des informations telles que le taux de lec-
ture et d’écriture pour les disques durs, le nombre de touches pressées pour le clavier, le
nombre de pixels affichés pour l’écran, etc. Ces informations peuvent être présentées de
manière tabulaire ou dans une vue défilante pour suivre l’activité en temps réel. (forme :
numérique/textuelle)
3. Après le Déroulement :
(a) Résumé de l’Exécution : Affichage des statistiques globales de l’exécution du logiciel,
telles que le nombre total de processus exécutés, la durée d’exécution totale, les éventuelles
erreurs ou avertissements rencontrés, etc. (forme : numérique)
(b) Historique des Événements : Journal des événements significatifs survenus pendant l’exé-
cution, tels que le démarrage et l’arrêt des processus, les opérations de lecture/écriture sur
les disques durs, etc. (forme : texte pour une lecture facile)

15
4 Manuel utilisateur
Cette section est dédiée au manuel utilisateur. C’est la seule section dans laquelle vous pouvez utiliser
des captures d’écran de votre logiciel.

Attention Comme d’habitude, toutes les figures doivent avoir un titre, être numérotées et expliquées
dans des textes.
En cas de nécessité, vous pouvez scinder naturellement cette section en des sous-sections corres-
pondantes à différentes aspects fonctionnels de votre logiciel.

16
5 Déroulement du projet
Dans cette section, nous décrivons comment le projet a été réalisé en équipe : la répartition des
tâches, la synchronisation du travail en membres de l’équipe, etc.

5.1 Réalisation du projet par étapes

5.2 Répartition des tâches entre membres de l’équipe

17
6 Conclusion et perspectives
Dans cette section, nous résumons la réalisation du projet et nous présentons également les extensions
et améliorations possibles du projet. Okayyy, j’ai capté

6.1 Résumé du travail réalisé

6.2 Améliorations possibles du projet

18
Références
[HLR02] L. M. Haas, E. T. Lin, and M. A. Roth. Data integration through database federation. IBM
Syst. J., 41(4) :578–596, 2002.
[HP11] John L. Hennessy and David A. Patterson. Computer Architecture, Fifth Edition : A Quan-
titative Approach. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 5th edition,
2011.

19