Devoir Système - 1998-1999
Simulation d'une installation d'ascenseur(s)
©
M. Laporte - D. Mathieu
mathieu@romarin.univ-aix.fr
I.U.T.d'Aix en Provence - Département Informatique

Sommaire
Sujet
Quelques pistes
Organisation
Outils
Travail à rendre
Le texte
Les listings
Annexe
Sujet : simulation d'une installation d'ascenseur(s) dans un immeuble
Il s'agit de concevoir et, si possible, de développer un système informatique permettant de simuler le comportement d'un ensemble d'ascenseurs dans un immeuble de plusieurs étages, en fonction de la demande d'individus que nous appellerons "clients".
On considérera qu'un ensemble est constitué d'au moins un ascenseur, et, s'il y en a plusieurs, ils sont regroupés géographiquement afin de desservir chacun l'ensemble des paliers.
Cela exclut les cas d'ascenseurs aux deux extrémités d'un même bâtiment (il s'agirait alors de deux systèmes indépendants), de plusieurs ascenseurs desservant chacun une partie des étages (par exemple un pour les pairs et un pour les impairs).
Les objectifs de ce devoir sont multiples : tester votre capacité à
-
analyser le problème (spécifications) : fonctionnement normal, cas particuliers, souplesse du système,
-
trouver des solutions adaptées aux différents problèmes envisagés,
-
mettre en œuvre ces solutions en utilisant les ressources que fournit UNIX.
Compte tenu de la généralité du sujet, chaque devoir ne peut être qu'unique ...
Cependant, les indications ci-dessous peuvent vous aider à limiter votre imagination débordante !
Sommaire
Quelques pistes
Le système simulé doit se rapprocher le plus possible d'un système réel, mais il existe toute une variété de systèmes réels ou réalisables.
Il existe des ascenseurs sans mémoire, les plus simples à gérer, mais un peu primitifs.
Il existe ou peut exister des ascenseurs optimisés individuellement - un ascenseur ne dessert pas les étages selon l'ordre chronologique des appels, mais selon l'ordre dans lequel il rencontre les étages - ou collectivement – les ascenseurs négocient entre eux pour décider dans quel sens ils vont.
De même, certains ascenseurs ne mémorisent que certains appels : vous montez au premier étage dans un ascenseur qui descend, vous appuyez sur l'étage 4.
L'ascenseur purge tous les appels lorsqu'il arrive en bas.
Votre appel est perdu et vous devez appuyer de nouveau sur l'étage 4.
En principe, chaque étage devrait être muni de deux boutons, l'un enregistrant les demandes de descente, l'autre les demandes de montée (attention au rez-de-chaussée et au dernier étage !).
A chaque ascenseur et à chaque client doit correspondre un processus unique.
Si besoin est, vous pouvez cependant utiliser des processus supplémentaires (peu conseillé, si possible, sauf solide justification !).
Pendant la phase de mise au point, vous pouvez lancer "à la main" chacun des processus nécessaires à partir du clavier.
Cependant, afin de tester sérieusement votre système, vous devrez concevoir des jeux d'essais correspondant à des cas spécifiques que vous bâtirez sous forme de scripts, soigneusement commentés.
Cela vous permettra de "rejouer" autant de fois les mêmes scénarios.
Ainsi, on peut imaginer un script lançant successivement :
-
un processus paramétré (nombre d'étages supposés numérotés à partir de 0, nombre d'ascenseurs avec contenance de chacun, vitesse de déplacement ( = nombre de secondes par étage), durée d'attente portes ouvertes à un étage avant de repartir, etc.) Ce processus pourrait être chargé de créer le(s) processus ascenseur, de créer la ou les ressources partagées si nécessaire, etc.
De même vous devez initialiser le système (position initiale des cabines, états des boutons d'appels, etc.
Si les clients sont stockés dans une file d'attente à chaque palier, il faut peut-être initialiser la file?
-
les différents processus clients, eux-mêmes paramétrés (délai avant d'arriver au palier de l'ascenseur, étage de départ, étage d'arrivée).
A vous de vérifier la cohérence des paramètres.
Dans un premier temps, vous pouvez ne traiter que des comportements "normaux", mais vous pouvez aussi prendre en compte des clients fous ou bizarres : client qui appelle pour descendre et qui, dans l'ascenseur, demande à monter, client qui monte dans l'ascenseur et qui en descend immédiatement avant la fermeture des portes, client qui reste indéfiniment dans l'ascenseur, etc.
Ces comportement pourraient être simulés soit en paramétrant différemment les processus clients, soit en créant des processus clients différents.
Vous devez gérer la capacité limitée des cabines, par exemple en ne laissant entrer les clients que l'un après l'autre, au moyen d'une simulation de tourniquet, et en bloquant les clients lorsque la cabine est pleine (pas très réaliste), ou bien en laissant entrer autant de client qu'ils le veulent, mais en bloquant la cabine jusqu'à ce que certains clients, excédés ou intelligents, décident eux-mêmes de descendre de l'ascenseur.
Imaginez la scène.
Au fait, seraient-ils obligés d'appuyer de nouveau sur le bouton pour rappeler une cabine ? On peut aussi imaginer que la cabine a une capacité maximale en nombre de personnes, mais aussi en charge.
L'ascenseur pourrait donc laisser rentrer n'importe qui dans la limite des places, puis calculer la charge totale.
Cela supposerait que les clients auraient un paramètre supplémentaire qui serait le poids.
Dès que l'application est un peu complexe, le déroulement de plusieurs processus parallèles ne peut être contrôlé directement par affichage de messages sur un écran.
Deux solutions s'offrent à vous :
-
une représentation graphique, permettant de suivre visuellement les déplacements des différentes entités.
Bien que très séduisante, cette solution vous consommerait beaucoup de temps alors qu'elle est à peu près hors sujet.
Ne l'envisagez que si le reste est très avancé.
-
un chronogramme dérouté sur fichier, seule méthode sérieuse de valider les programmes.
La trace temporelle sera assurée par un "estampillage" des messages : chaque message sera marqué de son heure d'émission, permettant de contrôler assez bien les enchaînements d'événements.
Sommaire
Organisation :
Après quelques jours de réflexion, vous devez commencer à imaginer la structure de votre devoir, les outils que vous utiliserez, ce que vous vous sentez capables de faire, etc.
Vous devez ensuite vous répartir rapidement le travail de façon équitable, spécifier au mieux les fonctions de chacun, quitte à faire évoluer ces spécifications au fur et à mesure des besoins.
Fixez-vous un calendrier prévisionnel de réalisation.
Si vous devez utiliser des outils de système non maîtrisés par exemple, essayez de ne pas être tous bloqués et de mener plusieurs activités en parallèle, quitte à court-circuiter provisoirement certaines parties (un sleep() remplaçant une action, une lecture au clavier remplaçant l'attente d'un événement quelconque, etc.)
Outils :
Pour nous, la partie la plus intéressante du devoir est la synchronisation et la communication des différents processus.
Vous pouvez utiliser tous les outils système que vous connaissez, et même ceux que vous ne connaissez pas encore, comme les pipes nommés - dont le comportement se rapproche beaucoup des pipes, mais qui permettent à des processus non parents de communiquer (un exemple suit en annexe) - ou les files de messages, qui ne seront pas étudiés en TP mais dont vous pouvez trouver le principe dans le polycopié des IPCs.
N'hésitez pas à créer des classes si elles vous paraissent nécessaires, mais ne vous forcez pas à en faire si cela ne vous paraît pas naturel.
C'est avant tout un devoir de Système !!!
Sommaire
Travail à rendre
Votre travail donnera lieu a la rédaction d'un rapport en deux parties :
-
le texte du rapport lui-même
-
les listings.
Le texte
Le texte a différents objectifs.
Il doit vous permettre de présenter globalement votre travail, afin de nous permettre de nous y retrouver plus facilement dans les listings.
Pour cela, vous devez expliquer le plus clairement comment vous avez compris le sujet, ce que vous avez traité.
Vous devez faire une présentation rapide de votre travail, comment il est structuré, comment l'ensemble fonctionne.
Quand vous estimez avoir donné suffisamment d'informations pour nous permettre d'entrer dans votre réalisation, vous devez développer plus précisément les points qui vous paraissent importants, difficiles, ou que vous jugez intéressants à mettre en valeur.
Nous sommes aussi intéressés par la façon dont vous vous êtes organisés, par les difficultés que vous avez rencontrées et la façon dont vous les avez surmontées.
Le sujet est très ouvert, vous pouvez donc imaginer de nombreux perfectionnements à votre travail, des généralisations, d'autres façons de résoudre le problème.
Cela nous intéresse, même si vous n'avez pas mené la réflexion jusqu'à la réalisation, à condition que vous ayez un peu pensé à la mise en oeuvre !
Enfin, nous aimerions un bilan de ce travail.
Pour résumer, le texte doit contenir les informations suivantes :
-
couverture indiquant les noms/groupes des auteurs et le titre,
-
sommaire paginé,
-
sommaire paginé des fichiers et des principales fonctions,
-
une analyse rapide de votre application (les différentes parties),
-
le planning prévisionnel, établi dès les premiers
jours,
-
le planning effectif, mettant en évidence les raisons des écarts
entre les deux
-
vos difficultés, trouvailles et autres,
-
ce qui marche et ce qui ne marche pas (mais comment vous aviez prévu
de le faire),
-
vos choix motivés de conception et d’implémentation,
-
l’organisation générale de votre travail, en terme de processus, structures de données et de contrôles,
-
un mode d'emploi indiquant les différentes possibilités, destiné à un utilisateur moyen
-
une présentation détaillée de votre travail, vos choix justifiés entre plusieurs possibilités,
-
l'organisation (la hiérarchie) des fichiers créés,
-
un bilan (ce qui manque, le temps que vous avez passé, vos frustrations et satisfactions éventuelles, etc.)
Les pages doivent être numérotées.
Attention : n’utilisez pas des polices de caractères trop grandes, des interlignes immenses, des changements de page abusifs pour que le rapport soit gros, donc pour essayer de nous faire croire que le travail est important ! ...
Sommaire
Les listings
Les listigns :
En résumé, tout ce qui peut mettre en valeur votre travail PERSONNEL... et rendre la correction la plus agréable et la plus facile.
Merci pour nous!
Commencez le plus vite possible, afin de voir venir les problèmes, rédigez en parallèle, au moins en prenant quelques notes.
N'hésitez pas à nous soumettre vos difficultés avant d'avoir perdu trop de temps.
Nous essaierons de vous aider à condition que vous fassiez l'effort de respecter la présentation.
Sommaire
ANNEXE
Vous pouvez créer un pipe nommé "fifo" par la commande Unix :
ou, par programme, comme dans l'exemple ci-dessous :
-
int ppal (int argc, char
* argv [])
-
{
-
if (nsSysteme::mkfifo
("fifo", S_IFIFO | 0700))
-
throw
CExcFctSyst ("mkfifo");
-
-
if (CSysteme::fork
())
-
{
-
char Chaine [] = "12345678911234567892123456789312";
-
int pfd = CSysteme::open ("fifo", O_WRONLY);
-
nsSysteme::write (pfd, Chaine, strlen (Chaine) + 1);
-
nsSysteme::close (pfd);
-
nsSysteme::wait ();
-
nsSysteme::unlink ("fifo");
-
}
-
else
-
{
-
char Chaine [MAX_INPUT];
-
int pfd = nsSysteme::open ("fifo", O_RDONLY);
-
sleep (2);
-
struct stat Stat;
-
nsSysteme::fstat (pfd, & Stat);
-
cout << "Taille = " << Stat.st_size << endl;
-
nsSysteme::read (pfd, Chaine, MAX_INPUT);
-
cout << Chaine << endl;
-
nsSysteme::close (pfd);
-
}
-
return
0;
-
-
} // ppal()
|
Sommaire
© D. Mathieu
mathieu@romarin.univ-aix.fr
I.U.T.d'Aix en Provence - Département Informatique