RAPPORT

PROJET
OPERATING SYSTEM

PROJET :
Mise en œuvre d’un
ordonnanceur pour la gestion
des processus

MEMBRES DU GROUPE :
 Moussa KANE
 Adama COULIBALY
Table des matières
INTRODUCTION.....................................................................................................................4
1 Présentation des algorithmes d’ordonnancement..........................................................5
1.1 ROUND ROBIN (RR).................................................................................................5
1.2 PRIORITY SCHEDULING (PS).................................................................................6
1.3 ORDONNANCEMENT RR & PS...............................................................................6
2 Implémentation du simulateur RR & PS........................................................................7
2.1 Présentation des technologies utilisées.....................................................................7
2.1.1 Le langage C++.....................................................................................................7
2.1.2 Microsoft Visual studio 2022................................................................................7
2.1.3 Les structures de données utilisées.......................................................................8
2.1.4 La bibliothèque wxWidgets..................................................................................8
2.2 Conception et fonctionnalités du simulateur...........................................................8
2.2.1 Implémentation en mode CLI...............................................................................9
2.2.2 Implémentation en mode GUI............................................................................14
CONCLUSION.......................................................................................................................24
 INTRODUCTION
Pour la gestion des processus dans un système mono ou multi processeur, chaque processus
doit être exécuté séquentiellement par le processeur. Dans de tels systèmes, le processeur est
affecté à chaque processus à un moment donné : on parle ainsi d’ordonnancement.
Lors de la réalisation de ce projet, nous avons eu à concevoir un ordonnanceur basé sur deux
algorithmes d’ordonnancements : ROUND ROBIN et PRIORITY SCHEDULING.
Dans ce rapport nous aurons ainsi deux grandes sections :
 La première section est la présentation des algorithmes d’ordonnancement utilisés
pour la conception du simulateur.
 La deuxième section concerne l’implémentation de l’ordonnanceur ainsi que sa
conception détaillée.
1 Présentation des algorithmes d’ordonnancement
L’ordonnancement est un processus permettant de déterminer quel processus possédera le
processeur pour l'exécution pendant qu'un autre processus est en attente. La tâche principale
de l’ordonnanceur est de s'assurer que chaque fois que le processeur reste inactif, le système
d'exploitation sélectionne au moins l'un des processus disponibles dans la file d'attente prête
pour l'exécution.

1.1 ROUND ROBIN (RR)

L’algorithme d’ordonnancement Round Robin est un algorithme d’ordonnancement
préemptif. Il utilise un concept de tranche de temps ou de quantum de temps. Le processus au
début de la file d’attente prête a la possibilité d’être exécuté en premier, mais uniquement
pour la durée du quantum unique.
Au fur et à mesure que de nouveaux processus sont ajoutés à la file d’attente des prêts, le
processus en cours est préempté et ajouté à la fin de la file d’attente des prêts. Le processus
suivant en a la chance, encore une fois pour la durée du quantum ponctuel. Cet algorithme est
conçu pour les systèmes à temps partagé.

Figure 1:Algorithme de planification Round Robin avec tranche de temps = 4 à temps = 0

Lorsqu’un processus est déjà exécuté par le processeur, il dispose d’un délai d’exécution
limité, mais s’il ne peut pas se terminer, il est préempté. Ainsi, au fur et à mesure que le temps
progresse, les chances que le processus soit préempté augmentent et sa priorité diminue. Alors
que le processus qui attend dans la file d’attente des prêts augmente ses chances d’obtenir le
processeur suivant. Ainsi, sa priorité augmente.

1.2 PRIORITY SCHEDULING (PS)

Priority Scheduling est l'un des algorithmes de planification les plus courants dans les
systèmes par lots. Chaque processus se voit attribuer une priorité. Le processus avec la
priorité la plus élevée doit être exécuté en premier et ainsi de suite. Les processus de même
priorité sont exécutés selon le principe du premier arrivé, premier servi.

Figure 2: Priority Scheduling

Dans la figure 2 le processus P1 s’exécute en premier parce qu’il a la priorité la plus élevé
suivie de P3 pour finir par exécuter P2.

1.3 ORDONNANCEMENT RR & PS

L’ordonnancement RR et PS implémenté dans ce projet consiste à combiner les deux
algorithmes d’ordonnancement ROUND ROBIN et PRIORITY SCHEDULING.
L’algorithme d’ordonnancement sélectionne le processus ayant la priorité la plus élevé, puis

Figure 3:Ordonnancement RR & PS

l’exécute en fonction du quantum de temps déterminé par Round Robin. Si deux processus
ont la même priorité, l’ordonnanceur sélectionne les processus par ordre d’arrivée et ainsi
sélectionne celui arrivé en premier dans la base.

2 Implémentation du simulateur RR & PS

Notre simulateur a été réalisé grâce au langage C++ avec comme IDE Microsoft Visual
Studio 2022. Nous allons ainsi commencer dans cette section par la présentation des
technologies utilisées, puis nous allons aborder les fonctionnalités du simulateur en expliquant
notre approche en même temps que sa conception détaillée et enfin nous allons montrer
comment nous l’avons implémenté en mode GUI avec la bibliothèque wxWidgets.

2.1 Présentation des technologies utilisées

2.1.1 Le langage C++
Le langage utilisé pour réaliser ce projet est le langage C++. Il est souvent utilisé pour créer
des applications qui exigent de hautes performances. C’est un langage de niveau intermédiaire
orienté objet à usage général et est une extension du langage C, qui permet de coder C dans un
"style C". Dans certaines situations, le codage peut être effectué dans l'un ou l'autre format,
faisant du C un exemple de langage hybride.
Le choix de ce langage pour ce projet a pour origine la façon dont l’on imaginait comment
devait se présenter l’interface qui affiche les traces d’exécution des processus par
l’ordonnanceur. Nous avons découvert que le langage C++ a une meilleure bibliothèque que
C pour l’implémentation d’une interface dynamique appelée wxWidgets mais aussi c’est un
langage orienté objet ce qui nous permet de mieux organiser notre code avec cette approche.

2.1.2 Microsoft Visual studio 2022

Visual Studio, grand frère de Visual Studio Code, est l’IDE principal de Microsoft.
Parfaitement adapté pour le développement .NET, il possède toutes les fonctionnalités d’un
éditeur de code ainsi que la possibilité de compiler, tester, lancer, publier et sauvegarder votre
code dans un espace de stockage.
L’une des fonctionnalités les plus importantes de Visual Studio est IntelliSense : un assistant
de complétion de code qui vous accompagne en listant chaque ligne de code que vous
produisez. Il analyse les membres, variables, mots clés et toute information ayant un lien avec
ce que vous êtes en train d’écrire.
L’une des principaux raisons de l’utilisation de cet IDE est le débogueur intégré (de l’anglais
debugging). Le débogueur permet de vérifier s’il y a des erreurs dans le code, et d’aider à
identifier la ou les causes et celui de Visual Studio est considéré comme l’un des meilleurs. Le
débogueur de Visual studio nous a beaucoup aidé lors de la réalisation de ce projet et nous
recommandons vivement cet IDE.

2.1.3 Les structures de données utilisées

Les structures de données en C et C++ sont utilisées pour stocker des données de manière
organisée et efficace. Le langage de programmation C a de nombreuses structures de données
comme un tableau, une pile, une file d'attente, une liste chaînée, un arbre, etc. Un
programmeur sélectionne une structure de données appropriée et l'utilise selon sa convenance.
Nous avons voulu implémenter deux structures de données dans ce projet en premier temps.
Nous voulions implémenter une liste de processus d’abord puis utiliser une fonction qui nous
permettrait de convertir la liste en arbre binaire de recherche pour trouver le processus ayant
la priorité la plus faible. Cependant durant l’implémentation, on a constaté que seule une liste
suffisait pour réaliser le travail demandé. Nous allons détailler l’implémentation de cette liste
dans la partie conception et fonctionnalités du simulateur (1.2).

2.1.4 La bibliothèque wxWidgets

WxWidgets est une bibliothèque C++ qui permet aux développeurs de créer des applications
pour Windows, MacOs, Linux et d'autres plates-formes avec une seule base de code. Il
possède des liaisons de langage populaires pour Python, Perl, Ruby et de nombreux autres
langages, et contrairement à d'autres kits d'outils multiplateformes, wxWidgets donne aux
applications une apparence et une convivialité véritablement natives car il utilise l'API native
de la plate-forme plutôt que d'émuler l'interface graphique. Il est également complet, gratuit,
open-source et mature.
Avec le langage C, la bibliothèque la plus populaire pour la programmation en GUI s’appelle
GTK. Nous avons jugé que l’implémentation de l’interface serait plus facile avec wxWidgets
et c’est l’une des raisons pour lesquelles nous avons choisi C++.

2.2 Conception et fonctionnalités du simulateur

La réalisation de ce simulateur a été faite en deux étapes. Tout d’abord nous avons voulu le
faire en mode CLI puis l’implémenter avec la bibliothèque wxWidgets en mode GUI. L’idée
est de faire en sorte d’avoir la possibilité d’ajouter des processus à une liste puis, de
sélectionner le quantum de temps et ensuite de démarrer l’exécution du simulateur.
L’utilisateur a aussi l’option de mettre en pause le simulateur pour voir les traces d’exécution,
de reprendre l’exécution mais aussi de stopper le simulateur. A chaque fois que l’exécution se
termine, la liste des processus est vidée et pour relancer l’exécution, il faut ajouter encore des
processus à la liste. L’utilisateur peut entrer le nom, le temps d’exécution, la priorité (entre 1
et 9) et l’ID de l’utilisateur. L’ID du processus est déterminé par le système car nous voulons
éviter que l’utilisateur puisse entrer deux processus ayant le même ID. Pour l’ordre d’arrivée
des processus, cela se fait au moment où un processus est ajouté à la liste. Donc à chaque fois
que l’utilisateur entre et valide les informations d’un processus, il est automatiquement ajouter
à la liste ce qui correspond à son ordre d’arrivée et à sa date de passage dans la base.
Pour le quantum de temps, nous l’avons mis par défaut à 1000ms (1s). Donc si l’utilisateur
décide ou oublie de mettre le quantum de temps, la valeur par défaut sera utilisée.

2.2.1 Implémentation en mode CLI

Dans cette section, nous allons expliquer comment nous avons implémenté le simulateur en
mode CLI. Cette section est une partie essentielle pour comprendre comment on a réussi à le
faire en mode GUI sans grande expérience dans la programmation en interface graphique.

2.2.1.1 Mise en place de la classe processus

Suite aux exigences du projet, nous devons modéliser les processus de la façon suivante :
 Id – Identifiant unique du processus (entier)
 Duration - Durée d’exécution (entier en millisecondes)
 RemainingTime - Durée d’exécution restante (entier en millisecondes)
 ProgramName - Nom programme en cours d’exécution (chaine)
 Priority - Priorité du processus (entier 1 à 9)
 UserId – Identifiant de l’utilisateur propriétaire du processus (entier)

Nous avons ainsi créé une classe Processus (figure 1) qui contient toutes les exigences de
modélisation comme attribut public. Nous avons aussi deux méthodes pour cette classe :
CreerProcessus( ) qui nous permet de créer un processus et AfficherProcessus( ) pour
afficher les informations d’un processus. Au niveau du constructeur (figure 2), le processus
est initialisé avec l’Id à 0, la durée à 0, le nom du programme à NULL, la priorité à 9, l’ID de
l’utilisateur à 0, le temps restant à 0.
 Figure 4: Classe Processus

Figure 5: Constructeur et Destructeur de la classe Processus

Nous pouvons constater dans les deux captures précédentes un pointeur suivant de type
Processus. Ce pointer va nous servir lors de l’implémentation d’une liste chainé simple pour
l’implémentation de notre liste de processus. Il est initialisé à NULL dans le Constructeur.

2.2.1.2 Mise en place de la liste de processus

La structure de donnée utilisée pour la liste de processus est une liste chainée simple. Elle
comprend 7 fonctions et une procédure.
 initialiser : Fonction qui permet d’initialiser une liste de processus
  insererEnTete : Fonction qui prend une liste de processus et un processus en
paramètre. Elle permet comme son nom l’indique d’insérer un processus en tête de
liste.
 insererEnFin : Fonction qui prend une liste de processus et un processus en
paramètre. Elle permet comme son nom l’indique d’insérer un processus en fin de
liste.
 afficherListeProcessus : Procédure qui prend une liste en paramètre puis affiche tous
les éléments de la liste.
 supprimer : Fonction qui prend une liste en paramètre puis supprime l’élément en tête
de la liste.
 supprimerMilieu : Fonction qui prend une liste et l’Id d’un processus en paramètre. Il
recherche dans la liste le processus qui correspond à l’Id donné en paramètre puis le
supprime.
 vider : Fonction qui prend une liste en paramètre puis supprime tous les éléments à
l’intérieur de la liste.
 sortList : Fonction qui prend une liste en paramètre, puis trie la liste de façon
décroissante en fonction de la priorité du processus. Si deux processus ont la même
priorité, celui qui est venu dans la base en premier sera en tête.

Figure 6: Fonctions et Procédures pour la liste des processus

2.2.1.3 Mise en place de la classe Scheduler

La modélisation de la classe Scheduler se présente comme suit :
 quantum – Quantum de temps (entier)
 liste – Liste de processus (ListeProcessus)

Nous avons créé une classe Scheduler (figure 4) qui contient les attributs définis
précédemment au niveau de la modélisation. Nous avons aussi deux méthodes pour cette
classe : defineScheduler( ) qui nous permet de définir le quantum de temps et startScheduler(
) pour démarrer le simulateur. Au niveau du premier constructeur (figure 5), la liste est
initialisée à NULL et le quantum à 0. Le deuxième constructeur quant à lui prend une liste et
le quantum de temps en paramètre pour initialiser les attributs liste et quantum.
 Figure 7: Classe Scheduler

Figure 8: Constructeur et Destructeur de la classe Scheduler

2.2.1.4 Réalisation du simulateur en mode CLI

Après avoir mis en place toutes les classes et les fonctions nécessaires, il nous reste à
implémenter le simulateur d’ordonnancement RR et PS. Tout d’abord il faut créer une liste de
processus. Pour aller plus vite, au lieu d’utiliser la fonction CreerProcessus( ), nous allons
statiquement définir les processus et les ajouter en fin de liste après avoir créé une instance de
type Processus et Scheduler. Après, on utilise la fonction sortlist() qui nous permet de trier
une liste de façon décroissante en fonction de la priorité des processus. Si deux processus ont
la même priorité, le premier processus à être entrer dans la liste sera choisi en premier.
Ensuite on utilise la méthode defineScheduler( ) de la classe Scheduler pour choisir le
quantum de temps et enfin la méthode startScheduler( ) est exécutée pour démarrer le
simulateur. A la fin de l’exécution, on utilise la fonction vider( ) pour vider la liste. Même s’il
n’y a plus aucun élément dans la liste c’est une bonne habitude de le faire pour éviter des
fuites de mémoire.

Figure 9: main capture1

Figure 10: main capture2

Nous pouvons noté dans à la figure 7 qu’on a appelé la fonction afficherListeProcessus( )

avant et après la méthode startScheduler( ). C’est pour voir si les processus dans la liste ont
bien été exécutés.
La figure 8 ci-dessous montre comment l’exécution se passe si on décide de lancer le
programme en mode CLI. Tout d’abord on nous demande le quantum de temps que l’on
définit à 100ms. Ensuite l’exécution démarre en nous affichant d’abord les processus de la
liste. Ensuite le programme reste comme figé pendant quelques secondes parce que le
simulateur est en train d’exécuter les processus à tour de rôle jusqu’à ce que le temps restant
des processus à s’exécuter se termine. A la fin de l’exécution, on nous signale qu’il n’y a plus
de processus dans la liste. Ce message est du à cause d’une instruction dans la fonction
afficherListeProcessus( ) à la ligne 38 présente dans la figure 7 qui affiche une liste de
processus alors qu’il n’y a plus de processus dans la liste.

Figure 11: Exécution du simulateur en mode CLI avec 2 processus

2.2.2 Implémentation en mode GUI

Dans cette partie, nous allons faire en sorte d’afficher les traces d’exécutions du simulateur
quand il est en activité. Pour réaliser cette tâche, nous avons décidé d’inclure une interface
graphique ou l’on pourra ajouter des processus, de définir le quantum de temps, d’avoir la
possibilité de pouvoir démarrer le simulateur, de le stopper, le mettre en pause et reprendre
l’activité. Il y aura aussi au niveau de l’interface une section qui nous permettra de voir l’état
des processus en exécution et ceux en attente.
Pour réaliser cette partie, nous aurons besoin de la bibliothèque open source wxWidgets. Nous
allons ainsi inclure un sample pour la gestion de thread qui va nous permettre d’y inclure
notre code et d’avoir la possibilité de l’ajuster avec le sample.
Le sample est présenté comme suis : nous avons une classe MyApp qui dérive de wxApp, une
classe MyFrame qui dérive deux classes, wxFrame et wxLog ce qui représente un cas de multi
héritage et une classe MyThread qui dérive de la classe wxThread.
2.2.2.1 Description de la classe MyThread
Cette classe permet de générer une instance pour l’exécution de notre simulateur. Elle dérive
de la classe wxThread. Elle comprend les attributs suivants :
 m_count – compteur (entier)
 myprocess – Instance processus (Processus)
 myscheduler – Instance scheduler (Scheduler)
Nous avons dans cette classe un constructeur MyThread( ) qui initialise un processus avec le
constructeur Processus( ), un scheduler avec le constructeur Scheduler( ). Nous avons aussi
initialisé tous les attributs dérivés de wxThread avec le constructeur wxThread( ). Le
quantum de temps de l’instance myscheduler se voit affecté la valeur 1000 ms par défaut ainsi
que le compteur qui est de 0.
Une méthode Entry( ) est aussi présente dans cette classe. C’est une méthode virtuelle qui
joue le rôle de point d’entrée au moment où le thread démarre. C’est dans cette section que
l’on va mettre les instructions de base pour le simulateur.

Figure 12: Classe dérivée MyThread

Figure 13: Constructeur MyThread

2.2.2.2 Description de la classe MyFrame

Cette classe a pour objectif de créer une fenêtre afin d’interagir avec le simulateur. C’est la
classe la plus importante du sample puisqu’elle nous permet de gérer les événements avec la
création des boutons. Nous avons dans cette classe les attributs suivants :
  logList – liste déroulante pour contenir des chaines de caractères (wxListBox)
 btnStart – le bouton Démarrer (wxButton)
 btnStop – le bouton Arrêter (wxButton)
 btnPause – le bouton Pause (wxButton)
 btnResume – le bouton Resume (wxButton)
 m_oldLogger – Définit une interface pour la journalisation (wxLog)
 mythread – une instance MyThread (wxThread)
Nous avons dans cette classe un constructeur MyFrame( ) qui prend en paramètre un
wxString pour le titre de la fenêtre. Ce constructeur initialise aussi les attributs du
constructeur wxFrame. Nous pouvons aussi noter à l’intérieur de ce constructeur que l’on a
ajouté un menu fichier avec les options suivantes : Ajouter des processus, Définir le
quantum de temps et Quitter. On a aussi un menu Aide avec une option Information pour
avoir les auteurs du simulateur.

Figure 14: Classe MyFrame

 Figure 15: Constructeur MyFrame

Nous pouvons constater au niveau de la figure 11 que nous avons 9 méthodes publiques, 1
méthode protected virtuelle et 1 méthode privée. Pour les méthodes publiques, nous avons :
 OnQuit : Cette méthode réagit à l’événement Quitter qui, comme son nom l’indique,
permet de fermer le frame créé.
 OnAbout : Cette méthode réagit à l’événement Information qui permet d’avoir les
informations sur l’auteur du simulateur.
 OnConfigure : Cette méthode réagit à l’événement Ajouter des processus qui permet
de créer des processus et de les ajouter à une liste.
 OnQuantum : Cette méthode réagit à l’événement Définir le quantum de temps qui
permet de déterminer le quantum pour l’ordonnancement.
 OnStart : Cette méthode réagit à l’événement Démarrer qui déclenche l’exécution du
simulateur les informations.
 OnStop : Cette méthode réagit à l’événement Arrêter qui permet d’arrêter l’activité
du simulateur et de réinitialiser la liste à NULL.
 OnPause : Cette méthode réagit à l’événement Pause qui permet de mettre en pause
l’activité du simulateur.
 OnResume : Cette méthode réagit à l’événement Reprendre qui permet de reprendre
l’activité du simulateur précédemment mise en pause.
 WriteList : Cette méthode permet d’écrire sur la section de journalisation les détails
du processus en activité et les informations sur les threads.
Nous avons une méthode protected DoLogRecord( ) qui transfert les messages de
journalisation au niveau de WriteList( ).
Une méthode privée CreateThread( ) est aussi présente pour la création de thread.
2.2.2.3 Description de la classe MyApp
Cette classe représente l’application elle-même. Elle est dérivée de la classe wxApp. Elle
comprend les attributs suivants :
 m_critsect – Instance wxCriticalSection (wxCriticalSection)
 m_threads – Instance wxArrayThreads (wxArrayThreads)
 m_semAllDone – Instance wxSemaphore (wxSemaphore)
 m_shuttingDown – Indication de l’arrêt de tous les threads (bool)
Cette classe a un constructeur par défaut MyApp( ) qui affecte false à la variable
m_shuttingDown et un Destructeur virtuel. Nous avons aussi une méthode virtuelle OnInit( )
(figure 12) qui est équivalente au rôle que joue la fonction main. Cette méthode est chargé de
généré la Frame principale de la classe MyFrame.

Figure 16:Classe MyApp

Figure 17: Constructeur MyApp et méthode OnInit

La figure suivante montre comment se présente l’interface graphique du sample.

 Figure 18: Simulateur RR & PS

2.2.2.4 Mise en place de la classe ProcessusDialog

Pour l’ajout des processus à la liste et pour la définition d’un quantum de temps, il faut créer
des boîtes de dialogues. Ces boîtes sont de petites fenêtres qui s’ouvrent à la suite d’un
évènement. Cette classe est indépendante du sample, donc nous avons implémenté cette classe
nous même pour réaliser ce qui était convenu au niveau de la modélisation. Les attributs
présentent dans cette classe sont :
 programName_Box– Zone de texte pour le nom du processus (wxTextCtrl)
 programTime_Box– Zone de texte pour le temps d’exécution du processus
(wxTextCtrl)
 programPriority_Box– Zone de texte pour la priorité du processus (wxTextCtrl)
 programUserid_Box– Zone de texte pour l’Id de l’utilisateur (wxTextCtrl)
 programQuantum_Box– Zone de texte pour le quantum de temps (wxTextCtrl)
Nous avons deux constructeurs dans cette classe. L’un est pour la création d’un dialogue pour
l’ajout de processus et l’autre est pour la définition du quantum de temps. Au niveau du
premier constructeur, en plus des zones de texte, nous avons créé deux boutons qui réagissent
à des événements CLOSE et APPLY pour l’ajout de processus. Deux autres boutons sont
aussi présents au niveau du quantum de temps : OK et CANCEL.

Figure 19: Classe ProcessusDialog

En plus des constructeurs et des attributs, nous avons aussi des méthodes. Nous avons 6
méthodes publiques et 2 méthodes privées.
 getProgramName : qui récupère le nom du processus entré dans la zone de nom
 getProgramTime : qui récupère la durée du processus entré dans la zone de temps et
le converti en int.
 getProgramPriority : qui récupère la priorité du processus entré dans la zone de
priorité
et le converti en int.
 getProgramUserid : qui récupère l’ID de l’utilisateur entré dans la zone de UserId
et le converti en int.
 getProgramQuantum : qui récupère le quantum entré dans la zone de quantum
et le converti en int.
 ReinitialiserField : qui réinitialise tous les champs après mis un processus à la liste.

Les deux méthodes privées (figure 15) sont :

 onUpdateOK_2 : qui gèle le bouton OK du quantum tant qu’il n’y a pas de valeurs
entrées.
 onApply : qui permet d’envoyer un signal afin d’ajouter un processus à la liste.
 Figure 20:Méthode publique ProcessusDialog

2.2.2.5 Réalisation du simulateur en mode GUI

Après avoir décrit toutes les classes utilisées dans le sample et la classe ProcessusDialog
implémenté, nous allons passer à la réalisation de notre GUI. Dans un premier temps il faut
intégrer nos bibliothèques Processus.h et Scheduler.h dans le projet. Ensuite quelques
modifications ont été faites par rapport à l’implémentation en mode CLI.
 Au niveau de la classe Processus, nous avons ajouté deux attributs privés
Nbre_de_passage et waiting_time. Nbre_de_passage détermine combien de fois
l’ordonnanceur exécute le processus et waiting_time indique le temps d’attente de
chaque processus avant son exécution. Nous avons aussi un attribut public
arrival_time qui stocke la date à laquelle le processus est entré dans la base.
 Figure 21: Classe Processus en GUI

Nous pouvons constater que des méthodes ont aussi été ajoutées. ProcessusEnAttente( )
renvoie les détails d’un processus en attente, add_waiting_time( ) calcule le temps d’attente
de l’instance, update_pass( ) met à jour le nombre de fois qu’un processus a été exécuté et
setArrivalTime( ) détermine la date d’arrivée du processus dans la base.
Au niveau de la classe Scheduler, nous avons enlevé que la méthode DefineScheduler( ).
Quant aux fonctions de la liste chainée, nous avons modifier afficherListeProcessus( ) pour
faire en sorte qu’on affiche la liste des processus en attente s’il y’en a .
Après avoir intégré les bibliothèques nécessaires, il faut gérer les boîtes de dialogue (ajout de
processus et quantum de temps).
Pour l’ajout de processus, il faut d’abord remplir les zones de texte du nom, du temps
d’exécution, de la priorité et de l’ID de l’utilisateur. Cela est géré par la méthode
OnConfigure de la classe MyFrame. Si tous les champs sont entrés, le processus est ajouté en
fin de liste avec sa date d’arrivée dans la liste. Un message est ensuite affiché pour nous dire
qu’un processus a été ajouté dans la liste. Si au moins un champ n’a pas de valeur, un
message nous est renvoyé pour nous dire de remplir tous les champs. A chaque fois qu’un
processus est ajouté à la liste, les champs sont réinitialisés et on peut à nouveau ajouter un
processus à la liste si on le souhaite. Tant que le bouton CLOSE n’est pas cliqué, l’utilisateur
peut ajouter autant de processus qu’il souhaite. A noter que les processus sont ajoutés en
ordre, donc si est processus P1 est ajouté en premier à la liste par rapport à un processus P2, le
processus P1 est considéré comme arrivé en premier et la date de passage dans la base nous le
confirmera.
 Figure 22: Boite de dialogue Ajouter des processus

Pour la définition du quantum de temps, l’utilisateur a le choix de le faire ou pas. La valeur

par défaut du quantum est de 1000 ms. Si il choisit de le faire, il ne peut entrer une valeur
inférieur ou égale à 0. Tant qu’une valeur n’est pas définit, il ne peut pas valider.

Figure 23:Boite de dialogue Definir le quantum de temps

Après avoir ajouter des processus et définit le quantum de temps, on peut démarrer le
simulateur en cliquant sur le bouton Démarrer.
 Figure 24: Simulateur en pause

On peut constater dans la figure précédente plusieurs choses. D’abord la date de passage dans
la base pour chaque processus montre que P1 est arrivé en premier suivi de P2, P3, P4 et P5.
On peut aussi constater que les processus sont triés en fonction de leur priorité. P2 ayant la
priorité la plus élevée est exécutée en premier suivit de P3, P5. P1 et P4 ont la même priorité,
le processus P1 étant arrivé en premier sera d’abord exécuté suivit de P4. Chaque processus
est exécuté à tour de rôle jusqu’à ce qu’il n’y ait plus aucun processus dans la liste.

CONCLUSION