REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA

RECHERCHE SCIENTIFIQUE
UNIVERSITE DES SCIENCES ET DE LA TECHNOLOGIE D’ORAN
USTO - Mohamed Boudiaf
Faculté des Sciences
Département d’Informatique

Mémoire du Projet de Fin d’Etudes

En vue de l’obtention du Diplôme d’Ingénieur d’Etat en Informatique

Thème :

Présenté par:
BARKA Fatima Zohra Option : Système Parallèle Distribué (SPD)
BARKA Abd eldjalil Mustapha Option : Système d’Information Avancé (SIA)

Encadré par : Membres du jury :

Mr BELKADI Khaled Mme NOUREDDINE
Myriam
Mr RAHAL Sid Ahmed

Promotion 2006/2007
 Remerciements

C e travail a été réalisé au Laboratoire Informatique, Modélisation

et Evaluation des Performances des Système (LIMEPS) du
département d’informatique de l’Université de Sciences et de la
Technologie d’Oran Mohamed Boudiaf (USTO-MB).

Nous remercions en premier lieu «Allah Allah » de nous avoir donné le

courage, la volonté, et la patience pour réaliser cette laborieuse besogne.

Nous tenons aussi à remercier chaleureusement notre encadreur Mr

BELKADI Khaled pour nous avoir accueillis, en nous proposant ce sujet très
intéressant, et aussi, pour les précieux conseils et encouragements qu’il nous a
prodigué, ainsi que pour sa grande disponibilité.

Nous tenons également à exprimer nos profond respect et nos

vifs remerciements à :

Mme Myriam NOUREDDINE pour nous avoir fait l’honneur de

présider notre jury de mémoire.

Mr Sid Ahmed RAHAL pour avoir accepter d’examiner notre

travail.

Le personnel du CHUO et plus particulièrement ceux de service pharmacie où

nous avons effectué notre stage

Nous remercions également les enseignants qui ont contribué à notre

formation.

Et enfin, nos sincères remerciements à toutes les personnes qui ont

contribué de prés ou de loin à la réalisation de ce travail.
 Dédicaces
Dédicaces

Je dédie ce modeste travail à

La personne la plus chère de ma vie, à celui qui m’a tout offert pour arriver à ce
stade, « mon papa ».

Ma charmante maman, celle qui m’a mis au monde et qui n’a jamais cessé de
m’entourer de son amour et sa tendresse.

Ma très chère grande mère et son amour inconditionnel

Mon cher frère Mohamed.

Ma petite sœur Meriem.

Mon frère et mon binôme Abd Eldjallil Mustapha, qui m'a accompagné durant
tout le déroulement de ce projet.

Mes amis fidèles : yasmine, zinab, rachida.

Mes chères amis : hafsa, fatima, torkia, amina, najet, ibtisème, amina, lila.

Toute ma famille et à tous ce qui m’ont aidé de près ou de loin surtout dans les
moments les plus difficiles.

À tous, je dédie ce travail.

Melle Fatima Zohra

 Dédicaces
Dédicaces

J e dédie ce présent mémoire à mes chers parents qui ont tout fait
pour me donner une bonne éducation et m’ont apporté leur
soutien moral et financier durant mes études.

A ma grand mère, mon frère, mes sœurs, et à tous les membres de

ma famille.

A ma sœur qui est mon binôme et avec qui j’ai eu le plaisir de

travailler et de partager des moments inoubliables.

A touts ceux qui ont un jour compté beaucoup dans ma vie.

Abdeljalill
 Sommaire
Introduction Générale ……………………………………………………. 3
Chapitre I : Généralités et Définitions
1. Introduction……………...……………………………………………..... 4
2. Système……………….………………………..……………................... 4
3. Modèle………………..………………………………………………….. 6
4. Modélisation………………………………….…………………………... 8
8
5. Simulation…………………......................................................................
9
6. Conclusion ………...……………….……………………………………
Chapitre II : Les Systèmes Hospitaliers
1. Introduction …………………………………………...…………………. 10
2. Système hospitalier………...…………………………………………….. 10
3. Système hospitalier d’Oran …………………………………….………... 10
3.1. Historique du CHU d’ORAN…………………………………..…….. 10
3.2. Les différentes Service du CHU d'Oran……………………………… 14
3.2.1. C.H.U.ORAN(Siége)….……………………………………………... 14
3.2.2. Les Cliniques ……………………………………………………….. 17
4. Conclusion ……………………………………………………………… 17
Chapitre III : La Méthodologie ASCI
1. Introduction …………………………………………...…………………. 18
2. Méthodologie de modélisation…………………………………………… 18
3. Environnement de modélisation………………………………………….. 18
4. Le processus de modélisation…………………………………………….. 19
5. Les trois sous systèmes…...……………………………………………... 21
6. Conclusion.……………...……………………………………………..... 22
Chapitre IV : Modélisation ARIS
1. Introduction …………………………………………...………...……….. 23
2. Architecture des systèmes d'information intégrés (ARIS)………………. 23
2.1. Le concept de l'architecture ARIS…………………………………… 23
2.2. Notions des Vues descriptives……………………………………..… 23
2.3. Niveaux descriptifs…………………………………………………... 25
3. Modélisation avec ARIS………………………………………………… 26
3.1. Modélisation au sein des vues………………………………………………. 26
3.1.1. Vue organisationnelle……………………………………………….. 26
3.1.2. Vue de données……………………………………………………... 28
3.1.3. Vue de fonctions…………………………………………………... 29
3.1.4. Vue des processus/vue de gestion…………………………………….. 31
4. Conclusion.……………...……………………………………………..... 32
Chapitre V : Simulation SIMULA
1. Introduction …………………………………………...……...………….. 33
2. Historique………………………………………………………………… 33
3. Installer et débuter avec SIMULA……………………………………….. 33
4. Le langage SIMULA……………………………………………………... 33
4.1. Structure d'un programme SIMULA…………...……………………. 33
 Sommaire
4.2. Les déclarations de base………………………………………………. 34
4.3. Les entrées/sorties……………………………………………………. 34
4.4. Les instructions de choix et de boucles……………………………….. 35
4.4.1. L'instruction IF…..…………………………………………………………… 35
4.4.2.L'instruction WHILE…………………………………………………………. 35
4.4.3.L'instruction FOR……………………………………………………………... 35
5. L’orienté objets dans SIMULA…………………………………………... 35
5.1. Définition d’une classe………………………………………………... 35
5.2. Création d’un objet …………………………………………………... 36
5.3. L’héritage……………………………………………………………... 36
5.4. Propriétés des objets dans Simula…………………………………….. 36
6. Les Outils de Simulation…………………………………………………. 37
6.1. La classe Simset ……………………………………………………… 37
6.2. La classe Simulation………………………………………………….. 38
7. Conclusion.……………...………………………………………............. 39
Chapitre VI : Mise en Œuvre et Résultats
1. Introduction …………………………………………...……...………….. 40
2. Le Service Pharmacie du CHUO………………………………………… 40
2.1. Définition ……………………………………………………………. 40
2.2. Méthodologie de modélisation……………………………………….. 40
2.2.1. Le modèle de connaissance…………………………………………… 40
2.2.1.1. Sous Système Physique……………………………………………. 42
2.2.1.2. Sous Système Logique ……………………………………………. 45
2.2.1.3. Sous Système décisionnel………………………………………….. 47
2.2.2. Le modèle d’Action…………………………………………………... 48
2.2.2.1. Modèle de files d’attente……………………………………........... 48
2.2.2.2. Modèle SIMULA…………………………………………………. 49
3. Interface de réalisation et initialisation du Programme…………………... 54
4. Conclusion.…………...…………………………………………….......... 57
Conclusion Générale………………….....……………………………… 58
Bibliographie………………….....…………………………………… 59
 INTRODUCTION
Les systèmes hospitaliers sont des systèmes complexes qui posent de nombreux problèmes
tels que leur dimensionnement, l’amélioration de leur efficacité ou simplement la compréhension de
leur fonctionnement. Ces problèmes sont des problèmes d'évaluation des performances qui peuvent
être résolus par modélisation.

La modélisation étant un outil d'aide à la décision permettant d'éviter des investissements

inconsidérés. Ce mémoire décrit une modélisation et une simulation du service pharmacie du
système hospitalier. Une méthodologie de modélisation ASCI (Analyse, Spécification, Conception
et Implémentation) est utilisée pour ce système. Cette méthodologie est basée sur la construction de
deux classes de modèles : le modèle de connaissance et les modèles d’action.

Le but de ce travail est de modéliser et de simuler le service Pharmacie du Centre

Hospitalier Universitaire d’Oran (CHUO), en suivant la méthodologie ASCI, et cela en utilisant
l’outil ARIS pour le modèle de connaissance et le langage SIMULA pour le modèle d’action.

Notre objectif consiste à étudier le temps de traitement pris par chaque secteur et personne
rattaché au service pharmacie. Cela nous permet d’estimer le temps total après une journée de
travail ou plus.

Ce mémoire se compose de six chapitres : Dans le premier chapitre on donne les

définitions des différents termes tels que système, modèle, modélisation et simulation. Le deuxième
chapitre décrit en générale le système hospitalier et en particulier le système Hospitalier
Universitaire d’Oran. La démarche ASCI (Analyse, Spécification, Conception, Implémentation) est
présentée dans le troisième chapitre. Dans les chapitres quatre et cinq, on présente respectivement
l’outil de modélisation ARIS et langage de simulation SIMULA. La mise en œuvre et les résultats
obtenus pour le service pharmacie sont donnés dans le chapitre six. A la fin de ce mémoire on
termine par une conclusion et quelques perspectives.

Dans le cadre de notre projet de Fin d’Etudes, on a effectué un stage au niveau du Centre
Hospitalier Universitaire d’Oran (CHUO), ce qui nous a permit de bien réaliser notre travail.
1. Introduction
D'une façon générale, la simulation et la modélisation sont des méthodes pour étudier les
systèmes, à l'aide de modèles. Dans les paragraphes suivants on va définir ces différents termes qui
seront utilisés tout au long du mémoire.

2. Système [Epm 07]

Dans la littérature on peut trouver plusieurs définitions du mot système. On a gardé et repris
quelques unes :

- Un système est un assemblage d'éléments reliés entre eux, compris dans un ensemble plus
grand. Le mot système dérive du grec "systema" qui signifie "ensemble organisé" et il veut
dire combiner, établir, rassembler [Wk1 07].
- Un système est défini comme une partie de matière délimitée par rapport au milieu extérieur.
Le milieu extérieur est le reste de l'espace entourant le système [Moh 07].
- Un système est un ensemble de concepts présentés sous une forme coordonnée selon une
règle donnée [Die 07].
- Pour De Rosnay (1975), un système est un ensemble d'éléments en interactions dynamiques,
organisés en fonction d'un but [Ara 00].
- Le Moigne (1977) considère le système comme "un objet qui, dans un environnement, doté
de finalités, exerce une activité et voit sa structure interne évoluer au fil du temps, sans qu'il
perde pourtant son identité unique" [Ara 00].

Un système est un ensemble de parties ordonnées. Ces parties ont chacune leurs lois et une
certaine indépendance. Par contre, le tout a ses lois propres, car il existe entre les parties, des liens,
des relations identifiables, au moins pour quelques-unes d'entre elles et qui s'enchaînent souvent
l'une à l'autre. Cet ensemble change avec le temps. Un système n'existe pas dans le vide, mais dans
un milieu qui réagit sur lui et qu'il influence. Il est le plus souvent soumis à des contraintes, et
n'existe que pour atteindre un but suivant un plan, et son fonctionnement est contrôlé [Epm 07].

On peut décrire un système de la façon suivante :

- identifier les éléments (objets d'intérêts appelés aussi entité).
- déterminer les attributs (propriétés d'intérêt) de ces éléments.
- spécifier les activités, i.e. tous les processus qui sont à l'origine des changements dans le
système.
Les systèmes sont classés selon diverses catégories (figure I.1.a et figure I.1.b).

Figure I.1.a : Classification des systèmes [Epm 07]

Figure I.1.b : Autre classification des systèmes [Epm 07]

Suivant son état un système est stable/instable, évolutif/explosif. Suivant l'état de ses
changements un système est continu/discret.

Un système peut être divisé en sous-systèmes. Que le système soit complexe ou simple, son
fonctionnement est le même (figure I.2). Il s'agit d'atteindre un but, un objectif, à partir des données
qui sont estimées ou calculées, puis converties par une opération qui se déroule suivant un plan.

Figure I.2 : Fonctionnement d’un système [Epm 07]

 Les entrées peuvent revêtir des formes variées. Dans un système de gestion, par exemple, on
peut les classer en trois catégories : l'information, l'énergie (humaine et matérielle) et les fournitures.
L'opération du système est le traitement qu'on fait subir aux entrées pour obtenir les sorties.
Les entrées, comme l'opération elle -même, peuvent être modifiées par le mécanisme de la
rétroaction.

Ce fonctionnement a pour but de maintenir la qualité et la quantité des sorties du système, et

comporte quatre éléments : une grandeur mesurable, sa mesure, la comparaison de cette mesure
avec une valeur de référence et finalement une action corrective.

C'est aussi par le même mécanisme de rétroaction que l'environnement modifie le système.
L'élément rétroaction est essentiel au fonctionnement et à la vie du système qu'elle agisse, soit par le
système lui même, soit par l'environnement : cette vie est faite de précision, de souplesse,
d'ajustement et de changement.

Un système doit avoir un certain nombre de critères de qualité telles que : la simplicité, la
souplesse, la fiabilité, l’économie et l’acceptation par les utilisateurs.

3. Modèle
Il n'est pas souvent pratique (parfois il n'est pas possible) d'expérimenter un système réel. Par
conséquent, l'étude de systèmes se fait généralement à l'aide de modèles [Epm 07].

De la même manière que le système, on trouve plusieurs définitions de la notion de modèle.

On reprend ci-dessous quelques unes :

- Un modèle est une représentation de la réalité. Exemple : Les modèles économiques

cherchent à représenter des phénomènes économiques (la croissance, le commerce
international) ou des entités (une entreprise, un ménage) [Wk2 07].
- Représentation simplifiée d'un processus.
- Représentation simplifiée d'une partie limitée de ce qui existe par rapport à ses éléments
[Boi 07].
- Objet visuel issu d'une phase d'analyse destiné à préparer certaines tâches à réaliser et à
améliorer ainsi la qualité du travail ainsi que la maintenance de la réalisation [You 07].
- Objet ou personnage réel ou figuré (photographie ou croquis) destiné à être reproduit, imité,
ou interprété [Pro 07].

Un modèle est une représentation de système, réel ou imaginaire, dans le but d'expliquer et
de prédire certains aspects de son comportement. Un même système peut être représenté par
différents modèles qui ont chacun un but particulier. Un modèle n'est donc ni vrai ni faux : sa valeur
se juge à la contribution qu'il apporte dans l'explication du système présenté. Le critère de
comparaison des modèles est utilitaire : le meilleur étant celui qui fait du monde réel les prédictions
les plus précises [Epm 07].
La classification des modèles est donnée dans la figure I.3 suivante :

Figure I.3 : Classification des modèles [Epm 07]

Les modèles reçoivent aussi les mêmes qualificatifs que les systèmes qu'ils représentent.

Le traitement d'un modèle se fait suivant 2 voies : la voie mathématique ou la voie de simulation
[Epm 07].

- la voie mathématique : On a les lois individuelles et les lois d’interconnexion des composantes
qui sont exprimées par des relations mathématiques.

Pour une formulation relativement simple, il est aisé d'analyser l'influence des facteurs par
des techniques mathématiques.

- la voie de simulation : on suit pas à pas des composantes et leurs relations sans les intégrer dans
une description d'ensemble.

Les qualités d'un modèle sont : [Epm 07]

- La Réalité : fournir des prévisions les plus proches possible du monde réel.
- La Simplicité : la concentration et la priorité données à un nombre restreint de
variables fondamentales.
- Le modèle est à mi-chemin entre les méthodes empiriques et spéculatives : c'est un
schéma. En effet, ses bases appartiennent au monde réel, sa manipulation est théorique,
ses résultats n'ont de valeur que s'ils sont confirmés par les faits.
4. Modélisation

On retrouve dans la littérature plusieurs définitions du mot Modélisation et qu’on a repris

ci-dessous :

- Définition usuelle : Opération par laquelle on établit un modèle d'un phénomène, afin d'en
proposer une représentation interprétable, reproductible et simulable [Die 07].
- représentation visuelle, à l'aide d'un logiciel, de phénomènes invisibles à partir d'algorithmes
et de modèles mathématiques [Cyb 07].
- La modélisation d'un objet est sa traduction en formes géométriques et en concepts
mathématiques [Vis 07].
- Technique qui consiste à restituer sous une forme compréhensible par l'ordinateur un objet
ou un phénomène quelconque [Cov 07].
- Représentation d'un objet (ou d'un phénomène) sur un ordinateur. Il existe plusieurs
méthode de modélisation, chacune différentes selon les logiciels utilisés [Moh 07].

5. Simulation
On peut définir la notion de simulation par :

- technique informatique permettant de reconstituer le déroulement d'un phénomène à

partir d'une modélisation mathématique (système d'équations) et de l'introduction de
quelques paramètres dont la valeur est choisie par l'utilisateur [Rés O7].
- Technique permettant de simuler par ordinateur des événements futurs probables. On
peut obtenir ainsi une estimation des taux de rendement et des indices de risque [Sun 07].
- Activité de formation destinée à refléter la réalité, qui peut aller d'un simple jeu de rôles
à une invasion militaire factice [Str 07].
- Reproduction artificielle ou représentation figurée d’un phénomène [Lar 05].

Les critères d'une simulation sont les suivants : [Epm 07]

- le modèle est un élément fondamental de la simulation. Sa manipulation a pour but de

présenter les diverses solutions d'un problème.

- la simulation est une méthode pratique, pour le choix des solutions, au moment de la
prise de décision.

Les buts de la simulation sont : [Epm 07]

- l’analyse des systèmes : expliquer le fonctionnement du système réel.

- la construction des systèmes : comparer plusieurs modes de construction des systèmes.
- l’entraînement & enseignement.
On peut classer la simulation selon les variétés du modèle (figure.I.4)

Figure.I.4 : Classification d’une simulation [Epm 07]

Les avantages d’une simulation sont : [Epm 07]

- mieux comprendre les anciens problèmes & possibilité de détecter les autres problèmes
insoupçonnés.
- excellente méthode de comparaison, d'amélioration et d'appréciation des risques.
- possibilité de vérifier les solutions obtenues par d'autres méthodes de mettre à épreuve
des modèles théoriques.

Mais la simulation à ces limites et qui sont : [Epm 07]

- ce n'est qu'une expérimentation sur le modèle.

- ne donne pas la solution optimale.
- n’est pas précise par nature (à cause des simplifications & extrapolations).
- mise au point toujours longue.
- les solutions générales s'obtiennent seulement par une induction à partir de cas
numériques.

6. Conclusion
On a définit différentes notions tels que système, modèle, modélisation et simulation et qui
sont essentielles dans notre mémoire. Dans le chapitre suivant on va étudier les systèmes
hospitaliers d’une manière générale et plus particulièrement le Centre Hospitalier et Universitaire
d’Oran (CHUO).
1. Introduction
Parmi les différentes catégories de systèmes qu’on a présenté dans le chapitre précédent on a
choisi le système hospitalier.
L’objet de ce chapitre est d’étudier plus particulièrement le système hospitalier universitaire
d’Oran (CHU d’Oran).

2. Système hospitalier [Bou 06]

De point de vue systémique, un système hospitalier est qualifié comme étant un système
socio-technique dont la mission principale est de prodiguer le meilleur soin au patient : c’est un
véritable système de production de soins (SP de soins).

Par rapport au système de production de bien, le SP de soins est distingué par deux aspects
fondamentaux : l’incertitude des processus de soins et leur complexité [Cnr 03] [Lad 05].

Le caractère incertain du processus de soins réside dans la diversité des gammes de soins, la
difficulté de les formaliser et de les standardiser, dans la variabilité de la durée des activités de soins,
et également, dans la singularité du patient. L’incertitude générée par le caractère humain a des
effets sur la complexité des opérations de production, sur leur durée et leur qualité [Lad 05].

La complexité est due d’une part au pilotage du système qui doit prendre en compte aussi
bien les objectifs globaux du système que ceux des acteurs, dont certains disposent de pouvoirs de
décision important. D’autre part, la complexité est imputé au caractère incertain des activités
impliquant la dimension humaine, et aussi aux informations traitées par le système d’information
hospitalier (diverses, multiformes, interventions de multiples acteurs,..Etc.)

En effet, utiliser les approches issues des sciences de l’ingénierie n’est pas suffisant. Il faut
les adapter aux spécificités du système hospitalier et, au besoin, de développer des approches
nouvelles [Lad 05].

3. Système hospitalier d’Oran [Afr 07]

3.1. Historique du CHU d’ORAN

L'origine du Centre Hospitalier Régional d'Oran (CHRO) remonte en 1877, année où fut
mise en chantier la construction du premier pavillon du nouvelle hôpital.

C'est six ans plus tard, en Avril 1883, que les malades du vieil Hôpital St Lazare, situé
Boulevard du 2ème Zouaves, venait occuper les nouveaux bâtiments du plateau St Michel (figure
II.1).

Régi au début par le décret du 23 Décembre 1874, puis par celui du 27 Décembre 1943, c'est
le décret n° 57-1090 du 3 octobre 1957, relatif aux hôpitaux et hospices publics d'Algérie, et
l'arrêté du 31 Décembre 1957 fixant les conditions d'organisation et de fonctionnement des
établissements hospitaliers qui donnèrent à l'hôpital civil la dénomination de " centre hospitalier
régional d'Oran ".
 Le centre hospitalier régional d'Oran couvre une superficie de 13 hectares et comprend en
plus des services administratifs, économiques, généraux et de laboratoires une capacité
réglementaire d'hospitalisation de 2142 lits pour une capacité réelle de 2922 lits.

Le centre est administré par une commission administrative assisté d'une commission
médicale consultative.

Cet ensemble deviendra, par suite de la création de la faculté de médecine d'Oran, et

conformément aux dispositions de l'ordonnance 58-1373 du 30 Décembre 1958, le"Centre
Hospitalier et Universitaire d'Oran" CHU ( figure II. 2 ).

Figure II.1 : Photos de l’ancien CHR d'ORAN [Afr 07]

Figure II. 2 : Photos du CHU d'Oran actuel [Afr 07]

Le CHU d’Oran est composé de différentes administrations qui sont présentées par un
organigramme (figure II. 3). On détaille les différents éléments de cet organigramme :
FigureII.3 :L’Organigramme d’un Centre Hospitalier Universitaire
 - La direction générale (DG) est composée d’un directeur général et d’un secrétaire
général
ère
Au niveau de la direction générale du CHU d'Oran (1 étage), le Directeur Général est
assisté par un personnel composé de :

1. Bureau d’ordre général où on trouve une secrétaire, une secrétaire de direction, deux
agents de saisie, un archiviste et un bureau du correspondant informatique.
2. Bureau de l’information et de la communication est chargé de la communication et
des média.
3. Bureau de la sécurité et de la surveillance générale.
4. Bureau des marchés, du contentieux et des affaires juridiques.

Au réez de chaussé de la direction générale on trouve la secrétaire du SG.

- La Direction des Ressources Humaines (DRH) est dirigée par une Directrice des
Ressources Humaines. Elle est composée de deux sous directions: Sous Direction du
personnel et sous direction de la formation.

La sous Direction du personnel est composée d’un bureau des carrières des personnels
administratifs, techniques et de services ; d’un bureau de la gestion des carrières des
personnels médicaux, paramédicaux et psychologues et d’un bureau des effectifs de la
régulation et de la solde.

La sous Direction de la Formation est composée d’un bureau de la formation et d’un

bureau de la documentation.

- La Direction des Moyens et Matériel (DMM) est dirigée par un directeur des Moyens
et Matériels. Elle est composée de trois sous directions:

La sous Direction des Services Économiques est composée d’un bureau des
approvisionnements ; d’un bureau de la gestion des magasins, des inventaires et des
reformes et d’un bureau de la restauration et de l'hôtellerie.

La sous Direction des Équipements et infrastructures et de la maintenance est composée

d’un bureau des équipements ; d’un bureau des infrastructures et d’un bureau de la
maintenance.

La sous Direction des produits Pharmaceutiques, de l'instrumentation et du

consommable est composée d’un bureau des produits pharmaceutiques et d’un bureau des
instruments et du consommable.

- La Direction des Activités Paramédicales et Médicales (DAPM) est dirigée par le

directeur des Activités Paramédicales et Médicales. Elle est composée de trois sous
directions:
La sous Direction des Activités Médicales est composée d’un bureau de l'organisation
et de l'évaluation des activités médicales; d’un bureau de la permanence et des urgences; et
d’un bureau de la programmation et du suivi des étudiants.
 La sous Direction des Activités Paramédicales

La sous Direction des Activités de la Gestion Administrative.

- La Direction des Finances et du Contrôle (DFC) est dirigée par un directeur des
Finances. Elle est composée de deux sous directions:

La sous Direction des finances est composée d’un bureau du budget et de la

comptabilité et d’un bureau des recettes et des caisses.

La sous Direction de l'analyse et de l'évaluation des Coûts est composée d’un bureau
de l'analyse et de la maîtrise des coûts et d’un bureau de la facturation.

3.2. Les différentes Services du CHU d'Oran

Les différents services du CHU se situent au niveau du CHU (Siège) et au niveau de ses
différentes cliniques qui lui sont rattachées.

3.2.1. C.H.U. ORAN (Siège)

Le CHU d’Oran occupe une superficie de 13 hectares. Il est composé de 42 services dont
9 extra-muros.
Il a une capacité de plus de 1488 lits dont 700 lits pour la Spécialité Médecine, 541 lits
pour la Spécialité Chirurgie, 136 lits pour la Spécialité Gynécologie et 111 lits pour le
Spécialité Pédiatrie ; et de 6000 travailleurs dont 1312 Personnels médicaux, 1751 Personnels
paramédicaux, 1761 Personnels administratifs et le reste représente le personnel technique, le
personnel de service et le personnel de sécurité.

Le tableau II.1 représente les différents services et laboratoires avec la légende

suivante :

Code : représente la Codification utilisée par le Service Pharmacie

(a) : Distribution par quinzaine du consommable du Laboratoire + films + Produit de

Radiologie + verrier + Pansements + Instrumentations + Réactifs

(b): Planning Hebdomadaire de Distribution des Médicaments et des solutés Massifs

: Notre Proposition pour les acronymes non existants

Ce tableau est réalisé à partir des documentions donnés par le Service Pharmacie et le
Service Ressources Humaines et de l’enquête qu’on a menée au niveau du CHU d’Oran
Code Désignation Acronyme Adresse Nombre de Lits (a) (b)
00 MALADE CHRONIQUE M CHRON CHU - - -
01 URGENCES MEDICALES UM CHU - 01/15 Mercredi
02 REANIMATION MEDICALE PAV.5 CHU 10 10/24 Mardi
03 HEMATOLOGIE HEMATO CHU 27 09/23 Dimanche
04 GASTRO-ENTEROLOGIE GAST CHU 60 09/23 Samedi
05 DERMATOLOGIE PAV.7 CHU 40 06/20 Dimanche
06 CARDIOLOGIE PAV.13 CHU 86 06/20 Mercredi
07 RADIOTHERAPIE R THER CHU 18 04/18 Lundi
08 REEDUCATION FONCTIONNELLE REED CHU 30 08/22 Mercredi
09 PNEUMOLOGIE A PNEUMO A CHU 56 03/17 Dimanche
10 PNEUMOLOGIE B PNEUMO B GLATARDS 40 03/17 Lundi
11 ONCOLOGIE ONCOL GLATARDS 40 03/17 Lundi
12 PSYCHIATRIE PAV.35 CHU 33 04/18 Samedi
13 NEUROLOGIE NEURO CHU 40 07/21 Samedi
14 NEPHROLOGIE NEPHRO CHU - 07/21 Mercredi
15 INFECIEUX INFEC GARNISON 70 11/25 Lundi
16 CLINIQUE CHIRURGICAL A CCA CHU 41 01/15 Mercredi
17 CHIRURGIE UROLOGIQUE PAV.8 CHU 56 02/16 Samedi
18 CHIRURGIE NEUROLOGIQUE CCB CHU 50 07/21 Mardi
19 CHIRURGIE PLASTIQUE PAV.2 CHU 22 05/19 Dimanche
20 URGENCES CHIRURGICALES UC CHU 44 01/15 Mercredi
21 CLINIQUE DE CHERURGIE INFANTILE CCI CHU 60 04/18 Mardi
22 CHIRURGIE GENERALE AIT IDIR PAV.10 CHU 113 04/18 Mercredi
23 CHIRURGIE THORACIQUE CH THOR GLATARDS 40 03/17 Lundi
26 CLINIQUE D’ORTHOPEDIE- CCF CHU 65 05/19 Dimanche
TRAUMATOLOGIE
27 MEDECINE INTERNE A MIA CHU 54 09/23 Dimanche
28 REANIMATION PEDIATRIQUE REAN CHU 08 06/20 Lundi
29 CLINIQUE D’ENDOCRINOLOGIE DIABETOLOGIE ENDOCRI FRONT DE MER 40 10/24 Mardi
30 O.R.L ORL CHU 78 01/15 Mardi
31 PEDIATRIE B MARF CHU 84 7-21 Dimanche
32 PEDIATRIE A (AMILCAR CABRAL) ST MICHEL BOULEVARD 19 02/26 Samedi
ADDA BENAOUDA
33 NEUROPHYSIOLOGIE NEUROPH CHU - - -
34 GYNECOLOGIE OBSTETRIQUE MATER CHU 136 06/20 Mercredi
35 CLINIQUE DE GYNECOLOGIE NOUAR AMONDIER - 02/16 Mardi
FADELA
36 CLINIQUE D’OPHTAMOLOGIE OPHTA FRONT DE MER - - -
37 HEMODIALYSE HEMOD CHU 26 08/22 Mardi
38 RHUMATOLOGIE RHUMA CHU 30 09/23 Lundi
39 CENTRE DE TRANSFUSION SANGUINE CTS CHU - 01/15 Mardi
41 REANIMATION NEO-NATALE NEO-NATALE CHU - 06/20 Lundi
Code Désignation Acronyme Adresse Nombre de Lits (a) (b)
42 LABORATOIRE D’IMMUNOLOGIE IMMUN CHU - 10/24 Mercredi
43 LABORATOIRE DE TOXICOLOGIE LAB TOXICO CHU - - -
44 MEDECINE LEGALE M LEGAL CHU - 03/17 -
45 LABORATOIRE D’ANATOMIE ANAPA CHU - 04/18 -
PATHOLOGIE
46 LABORATOIRE DE BIOCHIMIE LAB BIOCHI CHU - 01/15 Lundi
47 LABORATOIRE DE MICROBIOLOGIE LAB MICRO CHU - 01/15 Samedi
48 LABORATOIRE D’HEMOBIOLOGIE HEMOBIO CHU - 01/15 Mardi
49 RADIOLOGIE CENTRALE RC CHU - 05/19 Mardi
50 RADIO-GARNISON R GAR GARNISON - 11/25 Lundi
51 MEDECINE DE TRAVAIL MED.RAVAIL CHU - 12/26 Samedi
52 EPIDEMIOLOGIE EPI PLACE ROUX - 12/26 Mercredi
53 LABO-GARNISON LAB GAR GARNISON - 11/25 -
54 PHARMACIE D’URGENCES UPHAR CHU - - -
55 PROTHESES DENTAIRES C DENT PLACE ROUX - 11/25 Lundi
56 ORTHOPEDIE DENTO-FACIALE O.D.F PLACE ROUX - 11/25 Lundi
57 ODONTOLOGIE CONSERVATRICE O.C PLACE ROUX - 11/25 Lundi
58 PARODONTOLOGIE PARO PLACE ROUX - 11/25 Lundi
59 PATHOLOGIE BUCCO-DENTAIRE PAV.18 CHU - 11/25 Dimanche
60 URGENCES MEDICALE SAMU CHU - 11/25 Samedi
61 LABORATOIRE REANIMATION MEDICALE PAV.5 CHU - 17/24 Lundi
62 LABORATOIRE PHARMACIE CENTRALE LAB CENT CHU -
63 TOXICOLOGIE TOXICO CHU - 03/17 Mercredi
64 LABORATOIRE GENETIQUE BIOLOGIQUE LAB GBM CHU - - -
MOLECULAIRE
66 SERVICE PENAL PENAL CHU - Lundi Lundi
88 ORSEC ORSEC CHU - - -
99 PHARMACIE CENTRALE PH CENTR CHU - - -

Tableau II. 1 : les Services et les Laboratoires du CHU d’ORAN

3.2.2. Les Cliniques

Les cliniques suivantes sont rattachées au CHU Siège d’Oran, on trouve :

- La clinique « Amiral Cabrl ».
- La clinique « Ortho Traumatologie ».
- La clinique « Nouar Fadela » : dont particulièrement le service Gynécologie Obstétrique.
- La clinique « Hammou Boutlelis » avec ses 3 services : Anesthésie Réanimation;
Chirurgie Cardiaque et Chirurgie Vasculair.
- La clinique «Laribere » de Diabethologie.
- La clinique Dentaire .

4. Conclusion
Dans ce chapitre, on a présenté un système hospitalier d’une manière générale et nous avons
présenté l’historique, les différentes directions, les services et les laboratoires du Centre Hospitalier
Universitaire d’Oran. Le service pharmacie sera développé dans le chapitre VI.
Dans le chapitre suivant on va présenter la méthodologie ASCI (Analyse, Spécification,
Conception et Implémentation) qu’on a utilisée.

.
1. Introduction
Dans le chapitre précédent, on a présenté le centre hospitalier d’oran (CHU d’Oran) et pour
l’étudier on va utiliser une méthodologie de modélisation tel que ASCI (Analyse, Spécification,
Conception et Implémentation) que l’on va détailler.

2. Méthodologie de modélisation [Meb 06]

L’approche de modélisation ASCI (Analyse, Spécification, Conception et Implémentation)

que nous présentons a été proposée par Gourgand et Kellert [Gou 91] pour les systèmes de
production. Depuis, elle a été adaptée aux systèmes hospitaliers [Com 94], [Gou 05], [Cha 05],
[Fén 05] et [Meb 05]. Elle est basée sur la construction de deux classes de modèles : le modèle de
connaissance et les modèles d’action.

Le modèle de connaissance décrit la structure et le fonctionnement du système dans un

langage naturel ou graphique.

Un modèle d’action est une traduction du modèle de connaissance dans un formalisme

mathématique ou dans un langage de programmation (par exemple un langage de simulation)
permettant l’évaluation des critères de performances choisis.

3. Environnement de modélisation [Meb 06]

Le but principal de la méthodologie de modélisation consiste à établir un modèle de
connaissance aussi générique que possible et qui permet l'exécution de modèles d'action pour les
systèmes spécifiques du domaine. Le modèle de connaissance demeure un modèle ouvert qui est
enrichi par chaque étude de systèmes du domaine. La gestion de la connaissance et l'exécution des
modèles d'action impliquent l'aide fournie par un environnement de modélisation qui est ouvert afin
d'inclure de nouvelles méthodes et des outils plus efficaces. L'environnement de modélisation
(figure III.1) facilite l’échange d'informations entre les différents membres du projet et aide à la
conception des modèles d'action pendant la phase d'extraction de l'information à partir du modèle de
connaissance. C'est une tentative d’automatisation du processus de modélisation à l'aide de la
formalisation de la connaissance, de l'analyse de données pour la détermination des caractéristiques
du système, de la recherche opérationnelle et de la simulation pour l'évaluation. Les représentations
graphiques et les outils d'animation permettent de vérifier le fonctionnement correct du modèle.
Le premier modèle de connaissance concernant les entités et la structure du système
logistique hospitalier a été formalisé à l'aide de l'outil ARIS (Architecture of Integrated Information
System). Cet outil, suggéré par Scheer [She 02], convient pour décrire des organismes, des
processus et des activités [Gre 00], aussi bien que des modèles entité-association [Che 76].
Quelques parties du système hospitalier sont spécifiées avec le langage UML. Un module
supplémentaire de simulation est disponible pour ARIS, mais pour les besoins graphiques et surtout
d’animation 3D, l'outil de simulation Witness a été préféré, dans un premier temps, afin de
concevoir et mettre en application des modèles d'action.
 Figure III.1 : Environnement de modélisation [Gou 91]

4. Le processus de modélisation [Gou 94]

La modélisation est un ensemble de techniques qui permettent d’étudier et de comprendre la
structure et le fonctionnement d’un système. On construit un modèle représentant la réalité et trois
concepts se dégagent :
-un modèle doit avoir un caractère de ressemblance avec la réalité.
-un modèle doit constituer une simplification de la réalité.
-un modèle est une idéalisation de la réalité.
Lorsque le système existe, on parle de modélisation a posteriori, dans le cas contraire, on
parle de modélisation a priori.
La modélisation met en œuvre le processus décrit à la figure III.2. Il utilise les concepts de
modèle de connaissance et de modèle d’action.
Le modèle de connaissances ou de fonctionnement d’un système (ou encore modèle
descriptif de la structure et du fonctionnement d’un système) est une formation dans un langage
naturel ou graphique de la structure et du fonctionnement de ce système. Si le système existe, le
modèle de connaissance contient l’ensemble des connaissances acquises lors des phases
d’observation. Si le système n’existe pas, le modèle de connaissance contient les spécifications de
topologie et de fonctionnement imposées des concepteurs.
Le modèle d’action est une traduction du modèle de connaissance dans un formalisme
mathématique (par exemple une méthode analytique qui exploite la théorie des réseaux de files
d’attente) ou dans un langage de programmation (par exemple un langage de simulation). Il est
directement exploitable et fournit les performances du système modélisé sans recourir à la mesure
directe.
 L’exploitation du modèle de connaissance et du modèle d’action est appelée processus de
modélisation. Ce processus est généralement itératif et est composé de quatre étapes qui sont
l’élaboration d’un modèle de connaissance d’un système, l’obtention d’un modèle d’action à partir
du modèle de connaissance, l’exploitation du modèle d’action pour évaluer les performances du
système et l’interprétation des résultats et déduction des actions à effectuer sur le système.

Figure III.2 : Le processus de modélisation d’un système [Gou 94]

Chacune des étapes indiquées inclut une phase de vérification et de validation. Remarquons
qu’un modèle de connaissance a un potentiel d’exploitation très vaste. Il peut par exemple permettre
de spécifier et concevoir :
-un outil pour la gestion en temps réel du système, comme un tableau de bord.
-un système d’information…

Au niveau organisationnel, la construction d’un modèle de connaissance favorise la

compréhension de la structure et des fonctionnalités du système étudié. En effet, la connaissance
d’un système est détenue partiellement par des groupes de personnes de compétences et de
domaines d’activités très disparates. Cette connaissance est collectée et synthétisée dans un modèle
donnant une vue globale du fonctionnement du système. Le modèle de connaissance permet ainsi
une approche qualitative.
4. Les trois sous systèmes [Gou 94]

Bien que les trois sous systèmes physique, logique et décisionnel soit fonctionnellement
disjoints, ils sont néanmoins liés les uns aux autres. Les interactions entre ces sous systèmes sont
données par la figure III.3

Figure III.3 : Communication entre les trois sous systèmes [Gou 94]

Le sous système décisionnel agit à la fois sur le sous système physique (règles de gestion,
d’attribution des ressources,..) et sur le sous système logique (choix des activités). Le sous système
logique fournit au sous système décisionnel des informations sur les flux traités. Le sous système
décisionnel connaît également, à tout moment, l’état du système. Le sous système logique sollicite
la reconfiguration du sous système physique pour prendre en compte des variations significatives de
la charge du système.
Nous avons vu que ces sous systèmes peuvent être appréhendés de manière hiérarchique.
Deux méthodes de décomposition hiérarchique sont utilisées :

- une décomposition par strates qui a pour objectif de décrire un système à différents
niveaux d’abstraction en fonction des objectifs donnés. Cette décomposition hiérarchique
est utilisée pour décrire le sous système physique. Le comportement du système est
analysé en terme d’entrées, de sorties et de liaisons entre les sous systèmes. Le principe de
cette décomposition est basé sur la nécessité d’indépendance des niveaux d’abstraction.
Une hiérarchie organisée en strates traduit une arborescence de sous systèmes dont les
interactions mutuelles sont ramenées aux seules influences entre les sous systèmes d’une
même strate et entre strates adjacentes,
- une structuration par échelons est utilisée pour les systèmes organisationnels hiérarchiques.
Elle permet de décrire le sous système décisionnel. Cette décomposition est bien adaptée
pour structurer les centres de décision afin de prendre en compte comme critère de
décomposition l’horizon des prises de décision. En effet, la notion d’échelon est liée à la
structure complète d’un système décideur ou plusieurs sous systèmes traitent de
problèmes fortement corrélés.
 5. Conclusion

Dans ce chapitre on a présenté la méthodologie ASCI (le modèle de connaissance et le

modèle d’action), l’environnement de modélisation, le processus de modélisation et la
Communication entre les trois sous systèmes (logique, physique et décisionnel) dans le modèle de
connaissance.
On va détailler dans les deux chapitres suivants, l’outil de modélisation ARIS pour le modèle
de connaissance et l’outil de simulation SIMULA pour le modèle d’action.
1. Introduction
On a vu que pour modéliser un système hospitalier il faut choisir une méthodologie telle que
ASCI, ce dernier a besoin d’un outil de modélisation pour le modèle de connaissance. Pour cela on
a choisi ARIS (Architecture de Systèmes d'Information intégrés) que l’on va expliquer tout au
long de ce chapitre.

2. Architecture des systèmes d'information intégrés (ARIS) [Vil 04]

2.1. Le concept de l'architecture ARIS

La conception de l'Architecture de Systèmes d'Information Intégrés (ARIS) repose sur un

concept d'intégration dicté par une vision globale des processus de l'entreprise.

La conception de l'architecture se base tout d'abord sur un modèle développé pour les
processus d'entreprise et contenant toutes les caractéristiques principales nécessaires à la description
de processus d'entreprise. Le modèle complexe qui en résulte est décomposé en plusieurs vues.
Cette décomposition par vues permet alors de procéder à la description du contenu de ces vues à
l'aide de méthodes spécialement adaptées à chacune d'elles sans qu'il soit nécessaire de tenir compte
des multiples relations et liens que ces vues peuvent entretenir entre elles. Les relations entre les
vues sont ensuite prises en compte et regroupées sans redondances pour une vue générale des
chaînes de processus.

La deuxième étape permettant de réduire la complexité de l'architecture consiste à distinguer

différents niveaux descriptifs. Les diverses méthodes descriptives appliquées aux systèmes
d'information sont classées selon un concept Life-Cycle (Cycle de vie) en fonction de leur degré de
rapprochement avec les techniques de traitement de l'information. Ceci permet d'obtenir une
description approfondie de tous les aspects, depuis la problématique de gestion d'entreprise jusqu'à
la transposition technique.

Le concept ARIS fournit ainsi un cadre dans lequel des systèmes d'information intégrés
peuvent être développés et optimisés et dans lequel la transposition de ces systèmes peut être décrite.

C'est en particulier l'accentuation du niveau descriptif spécialisé qui permet au concept ARIS
de jouer un rôle d'orientation lors de l'élaboration, de l'analyse et de l'évaluation de chaînes de
processus économiques.

2.2. Notions des Vues descriptives

Les vues descriptives constituent le premier composant de l'architecture. Elles permettent de

simplifier les processus d'entreprise complexes en les décomposant. Cette décomposition en quatre
vues permet de procéder à la description du contenu de ces vues à l'aide de méthodes spécialement
adaptées à chacune d'elles sans qu'il soit nécessaire de tenir compte des multiples relations et liens
qu'elles peuvent entretenir entre elles. La présentation des ces vues est la suivante:
 Figure IV.1 : La Maison ARIS (Vues descriptives) [Vil 04]

- Vue organisationnelle (Organisation)

La vue organisationnelle fait apparaître les unités organisationnelles et les collaborateurs de
l'entreprise ainsi que leurs relations et leurs structures.

- Vue des données (Données)

La vue des données rassemble les événements et les états de l'environnement de référence
des entreprises.

- Vue des fonctions (Fonctions)

La vue des fonctions comprend les fonctions à exécuter (opérations) dans une entreprise
ainsi que leurs relations hiérarchiques.

- Vue de gestion (Processus)

Les relations entre les trois vues différentes sont mises en évidence dans la vue de gestion.
Les processus d'entreprise se trouvent au centre de la vue de gestion.
 2.3. Niveaux descriptifs

Figure IV.2 : La Maison ARIS (Niveaux descriptifs) [Vil 04]

Le deuxième composant de l'Architecture ARIS établit une distinction entre différents

niveaux descriptifs. L'architecture ARIS comprend les niveaux descriptifs suivants :

- Règles de gestion
Dans les règles de gestion, le concept d'application de gestion d'entreprise devant être géré
est donc représenté dans une langue descriptive suffisamment formalisée afin qu'il puisse servir de
base à une transposition cohérente dans les techniques de traitement de l'information. Cette
opération est également désignée comme modélisation sémantique.

- Concept informatique
Si le champ conceptuel des règles de gestion est transféré dans les catégories de la
transposition informatique, le niveau du concept informatique est atteint. Ce sont les méthodes ou
les transactions exécutant les fonctions spécialisées qui sont définies ici et non ces dernières. Ce
niveau peut être défini comme le lieu d'adaptation de la Description spécifique aux canevas
descriptifs généraux des techniques de traitement de l'information.
- Implémentation
Au niveau de l'implémentation, le concept informatique est converti en composants
informatiques concrets. La relation à la technique de traitement de l'information est ainsi établie. Le
niveau d'implémentation est étroitement lié au développement de la technique de traitement de
l'information et subit constamment des modifications de par ses cycles innovatifs fréquents.

Avec la constitution des vues et les niveaux descriptifs, nous vous avons présenté le concept
ARIS de manière concise.

Chacune des vues est décrite pour les trois niveaux : règles de gestion, concept informatique
et implémentation.

3. Modélisation avec ARIS

La méthode ARIS a servi de base au développement d'ARIS Toolset, un outil développe par
l'entreprise IDS Scheer AG, qui assiste les consultants et les entreprises lors de l'élaboration, de
l'analyse et de l'évaluation des processus d'entreprise. [Vil 04]

L'outil ARIS Toolset est un des outils de modélisation de la méthode ARIS Tool. Il a été
développé par l'entreprise Scheer IDS. ARIS a également sa langue de modélisation propre, qui n'a
aucun nom spécifique. La langue de modélisation contient environ 80 types de diagramme. Chacun
des types de diagramme a une liste d'objets permis, dont beaucoup sont communs à plusieurs types
de diagramme. Les types d'objet sont environ 110 mais ils sont séparés dans des groupes avec des
propriétés communes. Chaque type de diagramme définit aussi des liaisons permises entre des types
d'objet. Une liaison peut avoir des types définissant sa sémantique et attributs. [Vil 04]

Certains des types de diagramme ont une sémantique bien définie. Ceux-ci sont les
Diagrammes de Chaîne de Processus Evénementiel (CPE); le Diagramme de chaînes de processus
(DCP), la structure d'organisation (l'organigramme) et la modélisation de données (plusieurs sortes
des modèles Entité- Relations). [Vil 04]

Ces diagrammes seront décrits dans la partie suivante, lors de la modélisation du processus
gestion de commandes à l'aide de l'outil ARIS Toolset. [Vil 04]

3.1. Modélisation au sein des vues [Ids 00]

3.1.1. Vue organisationnelle

3.1.1.1. Règles de gestion

L'organigramme est un mode de représentation typique des structures organisationnelles. Il

permet, selon les critères de structuration choisis, de représenter les unités organisationnelles
formées (en tant que responsables des tâches) et leurs interconnexions.

Les unités organisationnelles sont les responsables des tâches à accomplir pour réaliser les
objectifs de l'entreprise.
 Les liens représentent les relations entre les unités organisationnelles. Pour une spécification
plus précise des rapports hiérarchiques, on distingue différents types de liaisons entre les unités
organisationnelles.

Lorsque les compétences fonctionnelles sont saisies dans les cases, l'organigramme
représente la répartition des tâches d'entreprise. Les unités organisationnelles et les personnes
peuvent également être caractérisées. Il est donc possible de définir, pour une unité
organisationnelle, s'il s'agit par exemple d'un service, d'un département ou d'un groupe; les
personnes peuvent être affectées aux types de personnes chef de service, chef de groupe ou chef de
projet.

La vue organisationnelle regroupe les utilisateurs et les unités organisationnelles ainsi que
leurs relations et leurs structures. Elle comprend un certain nombre de diagrammes, offrant chacun
un aspect distinctif. [Vil 04]

Les symboles utilisés dans les diagrammes organisationnels : [Vil 04]

3.1.1.2. Concept informatique - Topologie de réseau [Ids 00]

La structure de l'entreprise représentée dans l'organigramme peut désormais être gérée par
des systèmes de communication et d'information. Les exigences posées à l'organisation structurelle
de ces systèmes d'information peuvent être définies en premier lieu dans le concept informatique
sous forme de topologies de réseau.
-La Figure IV.3 illustre un exemple de type de réseau.

Figure IV.3 : Représentation graphique d'un type de réseau [Ids 00]

3.1.1.3. Implémentation-Diagramme de réseau [Ids 00]

La représentation de la réalisation concrète de la topologie de réseau spécifiée dans le concept

informatique a lieu dans le diagramme de réseau.

3.1.2. Vue de données

3.1.2.1. Règles de gestion [Ids 00]

Les règles de gestion de la vue des données contiennent la description du modèle de données
sémantique du domaine de recherche concerné. Selon le principe de décomposition d'ARIS, les
objets permettant la spécification des événements de départ et de fin, ainsi que les descriptions
d'état du cadre pertinent d'une chaîne de processus, sont décrits.

La méthode de conception la plus répandue pour les modèles de données sémantiques est le
modèle entité-relation (MER) de Chen [Che 76]. Cette méthode de modélisation fait appel à des
termes aussi divers que type d'entité, type de relation, attribut, etc. De nombreuses relations existent
entre ces objets ; elles sont en outre bien plus difficiles à classifier que pour la modélisation de
fonctions.

3.1.2.2. Concept informatique [Vil 04]

Dans le concept informatique de la vue des données, le modèle sémantique est converti en un
modèle logique de base de données. Pour cela, le système utilise des diagrammes de relations, qui
représentent l'affectation des types d'entités et des types de relations aux relations.

Le diagramme de relations des attributs permet de définir les relations et les attributs ainsi
que leurs relations aux objets d'information introduits dans les règles de gestion.

Une relation logique décrit un type d'entité en utilisant ses attributs. Elle est un sous-ensemble
de combinaisons possibles de plages de valeurs de tous les attributs.

-Les relations sont représentées graphiquement comme suit : [Ids 00]

Figure IV.4 : Diagramme de rattachement Figure IV.5 : Diagramme de rattachement

d'attributs [Ids 00] d'attributs [Ids 00]

3.1.2.3. Implémentation - Diagramme de table [Ids 00]

Le diagramme de table permet de décrire les tables et les champs d'un système de base de
données.
 La représentation graphique de tables et de champs est montrée :

Figure IV.6: Représentation graphique de tables et de champs [Ids 00]

3.1.3. Vue de fonctions

3.1.3.1. Règles de gestion [Vil 04]

Les arbres de fonctions permettent de représenter la structure hiérarchique des fonctions

apparaissant dans une entreprise. L'affectation des fonctions à leurs sous- fonctions dans un arbre
peut être orientée objet, opération ou processus.

Les fonctions peuvent être décrites à différents niveaux de consolidation. Le niveau de

consolidation supérieur est constitué de fonctions rassemblées sous la forme de processus
d'entreprise ou de chaînes de processus. Il peut s'agir par exemple du traitement d'une commande
client depuis le traitement de la demande du client jusqu'à l'expédition. Un tel processus d'entreprise
est une fonction complexe qui peut être décomposée en sous fonctions en vue de réduire sa
complexité. Ainsi, le terme ' fonction ' peut être utilisé à tous les niveaux hiérarchiques. Cependant,
des termes tels que procédure, processus, fonctions partielles ou fonctions élémentaires sont
souvent employés pour une meilleure compréhension du niveau hiérarchique.

La décomposition des fonctions peut s'effectuer sur plusieurs niveaux hiérarchiques. Dans
les arbres de fonctions sémantiques, les fonctions élémentaires forment le niveau inférieur.

Les fonctions élémentaires sont des fonctions qu'il n'y a pas lieu de décomposer pour
répondre aux besoins de la gestion d'entreprise.

Cette décomposition est représentée dans des arbres de fonctions ou des diagrammes de
hiérarchie. Dans un arbre de fonctions, les fonctions peuvent être regroupées suivant différents
critères. Parmi les critères fréquemment utilisés, on peut citer le traitement du même objet
(orientation objet), la décomposition selon l'appartenance à un même processus (orientation
processus) ou le regroupement de fonctions selon les opérations (orientation opération).

La représentation de fonctions dans un arbre de fonctions permet certes une simplification,

elle reste cependant statique. En plus de la représentation statique, il peut être intéressant de
représenter l'enchaînement par le déroulement temporel des fonctions.
Les fonctions sont symbolisées par des rectangles aux angles arrondis : [Ids 00]

Figure IV.7: Représentation de la fonction « Vérifier la demande client » [Ids 00]

3.1.3.2. Concept informatique - diagramme de type d'application [Ids 00]

Le concept informatique de la vue des fonctions comprend la définition de types

d'applications, de types de module, de la structure modulaire des types d'applications, du projet
d'étapes, ainsi que la définition des présentations d'entrée et de sortie sous forme de concepts de
listes et de masques.

Le Type d'application est donc le type d'objet central du concept informatique de la vue des
fonctions.

Le diagramme de type d'application permet également de définir les fonctions des règles de
gestion qui sont soutenues par les types d'applications et les types de modules définis. Cette
affectation forme ainsi le lien entre les règles de gestion et le concept informatique de la vue des
fonctions.

-Les types d'applications sont représentés graphiquement comme suit :

Figure IV.8 : Représentation graphique d'un type d'application [Ids 00]

3.1.3.3. Implémentation - Diagramme d'applications [Ids 00]

Dans le diagramme d'application, il est possible d'affecter les applications et les modules
concrets aux types d'applications et aux types de modules du concept informatique. Il s'agit ici des
exemplaires d'un type d'application dont dispose une entreprise, qui sont p. ex. identifiables grâce à
leur numéro de licence.
-Les applications et les modules sont représentés graphiquement :

Figure IV.9 : Représentation graphique de l'application et du module [Ids 00]

3.1.4. Vue des processus/vue de gestion

Les relations entre les trois vues différentes sont mises en évidence dans la vue de gestion
(processus). Les processus d'entreprise se trouvent au centre de la vue de gestion. Parmi les
diagrammes utilisés dans cette vue on trouve :

3.1.4.1. La Chaîne de processus événementielle (CPE) [Vil 04]

Les CPE permettent de représenter l'organigramme d'entreprise, c'est à dire de représenter

les relations entre les objets des vues des données, des fonctions et des vues organisationnelles, et
par conséquent de représenter les processus.

Type d’objet CPE

Unité organisationnelle

Groupe

Poste de travail

Type de personne

Personne

Catégorie des connaissances

Connaissances documentées

Support d’information

Type de matières
 Type d’objet CPE

Type de système de transport

Type de moyens d’exploitation

Type de moyens auxiliaires techniques

Type d’emballage

Type d’installations d’entreposage

Tableau IV.1 : Tableau des symboles des types de modèles CPE [Ids 00]

3.1.4.2. Diagramme de rattachement de fonctions (E/S) [Ids 00]

En plus de la représentation de la gestion des événements illustrée au par avant, la

transformation de données d'entrée en données de sortie et la représentation des flux de données
entre les fonctions représentent également une liaison entre la vue de données et la vue des
fonctions du concept ARIS.

3.1.4.3. Diagramme de chaîne de processus (DCP) [Vil 04]

Dans ce diagramme de chaînes de processus, sont représentées toutes les vues relatives à un
processus d'entreprise (vue organisationnelle, vue des données, vue des fonctions et vue des
ressources) ainsi que leurs relations apparaissent sous une forme structurée.

4. Conclusion

D’après ce chapitre, on peut dire que la méthode ARIS est robuste et elle est plus adaptée
aux processus complexes de production ; et que le concept d’ARIS offre ces possibilités aussi bien
en ce qui concerne les questions de gestion et d’organisation que la mise en œuvre des systèmes
d’information.
Dans le chapitre suivant on va représenter l’outil de simulation SIMULA pour le modèle
d’action de la méthodologie ASCI.
1. Introduction
On a présenté dans le chapitre précédent l’outil de modélisation ARIS qui spécifier l’utilité
du modèle de connaissance, et pour le passage de ce modèle vers un modèle d’action on va utiliser
un outil de simulation.
Parmi les outils de simulation (QNAP2, Witness, SIMULA,…etc.) on a choisi SIMULA et que
l’on va détailler tout au long de ce chapitre.

2. Historique
SIMULA est le premier langage de programmation orienté objets, développé dans les années
60, par Ole Johan Dahl et Kristen Nygaard du Norwegian Computing Center (NCC) à Oslo
(Norvège) à partir d’un autre langage : Algol 60, pour traiter des problèmes de simulation de
processus physiques et introduit pour la première fois les notions de Classe et d’Objet.

SIMULA est passé par différentes étapes :

- Simula I (1964-1965) : SIMUlation Language. Langage de simulation.

- Simula 67(1967-1971) : Simple universal language. Langage général orienté objet
avec un système de classes supportant les listes (la classe système : Simset).

3. Installer et débuter avec SIMULA

- Copier le répertoire SIM sous c :

- Ouvrir un invité de commande;
- Entrer dans le répertoire Sim
- pa↵ path ↵
- Écrire le programme dans le bloc note
- L’enregistrer avec l’extension .SIM
- Compiler le programme avec la commande Sim puis l’exécuter

4. Le langage SIMULA

Comme tout langage de programmation, Simula possède une structure et une syntaxe
comprenant les déclarations des différents types, procédures, …en plus de la partie orientée objets.
Dans la section suivante, on va aborder la syntaxe de Simula.

4.1. Structure d'un programme SIMULA [Vau 97]

L’exemple suivant montre la structure d'un programme SIMULA :

 Begin
! Programme simple;
Integer i,j;
Integer carre;
i:= inint; j:= inint;
carre := i*i;
outtext(" i carre somme");
outimage;
outint(i,5);
outint(carre,5);
outint(i+j, 6);
outimage;
end.

Un programme SIMULA est un bloc débutant par Begin et se terminant par End de la
forme :

Begin
< Déclarations>
< Enoncés>
End

Le caractère ! est le délimiteur de commentaires.

4.2 Les déclarations de base [Vau 97]

Les types de base dans Simula sont les types : entier, réel, booléen, référence (ou pointeur) et
texte (chaîne de caractères).

- Les Entier : Integer i; integer i = 10;

- Les Réels : Real R; Real pi=3.1416;
- Les Booléens : Boolean b;
- Les Caractères : Character c;
- Les références (pointeurs): Ref(x) p ;
- Les chaînes de caractères : Text t;

4.3. Les entrées/sorties [Vau 97]

Chaque type de donnée possède une fonction d'entrée et une fonction de sortie qui transfère
une valeur à la fois. Pour les écritures, on doit spécifier la taille des champs. Le tableau V.1 suivant
résume les différentes fonctions relatives à chaque type.

Lecture Sortie
Integer I:= inint ; outint(I,10) ;
Real X:= inreal ; outreal(X,2,10);
Character C:= inchar ; outchar( C ) ;
Text T:= intext(20) ; outtext(" OK !") ;

Tableau V.1 : Entrées/Sorties en Simula [Vau 97]

4.4. Les instructions de choix et de boucles [Vau 97]

4.4.1 L'instruction IF

If C then <énoncé autre que IF> else <énoncé>

Exemple:
I:= if a+b>0 then I+1 else I-1;

4.4.2 L'instruction WHILE

While <expression > Do <instruction>

Exemple:
While i<10 do i:=i+1

4.4.3 L'instruction FOR

Exemples:
for I:= 1 step I+1 until 100 do ...;
for I:= 100 step -1 until 1 do ...;
for I:= 1,I+3 while I**2 < 100 do ...;
for I:= 2,3,5,7,11 step 4 until 51 do ...;
for C:= 'A','E','I','O','U','Y' do ... ;
for P:- P1,P2,P3 do ...;

5. L’orienté objets dans SIMULA

Simula est considéré comme le premier langage de programmation orienté objets. Pour cela,
il offre la possibilité de définir des objets, des classes et l'héritage.

5.1. Définition d’une classe [Tou 91]

Une classe peut être définie comme une structure de données à laquelle on ajoute des
fonctions permettant de manipuler les données de cette structure. Une classe est un type abstrait. Un
objet est une représentation de la classe obtenue dynamiquement au moment de l’exécution du
programme.

-Une classe en SIMULA est définie de la manière suivante :

class classe (paramètres); type des paramètres;

begin
Déclaration des variables et des fonctions;
Initialisations
end
 Exemple :

CLASS POINT (X,Y); REAL X,Y;

BEGIN
REAL PROCEDURE DIST;
BEGIN DIST:= SQRT(X**2 + Y**2) END;
END;

5.2. Création d’un objet [Vau 97]

Les objets spécifies par des classes doivent être crées dynamiquement par l'opérateur NEW
et on les accède par des pointeurs (REFERENCES).

REF(POINT) P;
...
P:- NEW POINT;
P.X:= 1; P.Y:= 3.0;
P.DIST:= SQRT (P.X**2 + P.Y**2);

5.3. L’héritage [Tou 91]

Une classe B peut hériter des propriétés d’une classe A en préfixant sa déclaration :

class A (paramètres); déclaration des paramètres;

begin
Déclaration d’attributs de A;
Actions d’initialisation A;
end;

A class B (paramètres); déclaration des paramètres;

begin
Déclaration d’attributs de B;
Actions d’initialisation de B;
end;

5.4. Propriétés des objets dans Simula

- Les classes sous Simula ont des bilans sur leurs états
- Les objets à travaillent comme des processus qui peuvent s'exécuter en quasi-parallèle.
- Les objets peuvent interrompre temporairement leur exécution pour donner le contrôle à un
autre processus.

Deux constructeurs : Detach et Call, sont utilisés pour passer le contrôle entre les différentes
instances d’objets :

Detach permet d'arrêter l'exécution d'un objet. Le premier appel à Detach retourne le
contrôle au point ou l'objet à été créé. L'exécution du reste de l'objet peut être reprise plus tard par
l'appel de l'opérateur Call. Les prochains appels de Detach arrêtent l'exécution de l'objet et passent
le contrôle aux points d'appel de l'objet.
6. Les Outils de Simulation

Les bibliothèques SIMSET et SIMULATION présentes dans la distribution de SIMULA

permettent d’utiliser ce langage comme outil de simulation [Tou 91].

La bibliothèque SIMSET contient les primitives de création et de manipulation de listes

doublement chaînées. Cette classe permet, entre autres, en simulation de gérer l’échéancier du
simulateur [Tou 91].

La bibliothèque SIMULATION, construite au dessus de la bibliothèque SIMSET, contient

les outils nécessaires à la réalisation d’un simulateur événementiel. Les classes dérivées de la classe
Process, présente dans cette bibliothèque, permettent de créer un ensemble de tâches indépendantes
disposant de leur propre espace d’adressage. Cette notion est à rapprocher de la notion de thread
que l’on trouve dans les systèmes d’exploitation modernes [Tou 91].

Dans ce qui suit, nous allons présenter chacune de ces classes.

6.1. La classe Simset [Vau 97]

Les listes de SIMSET sont circulaires à deux sens avec têtes de listes. Trois classes sont
définies : HEAD qui décrit les têtes de listes et comprend les procédures et fonctions s'appliquant
aux listes, par exemple FIRST pour donner le premier élément d'une liste; LINK que l'usager utilise
comme préfixe aux objets qui seront membres de listes; et LINKAGE, préfixe commun à HEAD et
LINK afin de permettre le chaînage.

-Voici le squelette de la classe SIMSET.

CLASS SIMSET;
BEGIN
CLASS LINKAGE;
BEGIN
REF(LINK) PROC SUC ; ...;
REF(LINK) PROC PRED; ...;
REF(LINKAGE) PROC PREV; ...;
END;
LINKAGE CLASS HEAD;
BEGIN
REF(LINK) PROC FIRST ; ...;
REF(LINK) PROC LAST ; ...;
BOOLEAN PROC EMPTY ; ...;
INTEGER PROC CARDINAL;..;
PROC CLEAR ; ...;
END;
LINKAGE CLASS LINK;
BEGIN
PROC OUT ;...
PROC FOLLOW (X); REF(LINKAGE) X; ...
PROC PRECEDE(X); REF(LINKAGE) X; ...
PROC INTO (L); REF(HEAD) L ; ...
END;
END;
 Figure V.1 : Représentation des listes chaînées définies par la classe SIMSET [Tou 91]

6.2. La classe Simulation [Vau 97]

SIMULATION est une classe qui introduit le concept de PROCESS afin de décrire des
objets dont la synchronisation est basée sur l'évolution du temps. Avec cette classe comme préfixe,
l'usager n'utilise plus les primitives RESUME, DETACH et CALL qui font des transferts de
contrôle explicites. Par contre, des procédures de plus haut niveau sont fournies pour qu'un
PROCESS qui veut s'arrêter temporairement puisse indiquer l'heure (EVTIME) à laquelle il désire
continuer. Tous les PROCESS actifs sont chaînés dans un échéancier SQS(SeQuencing Set) par
ordre croissant de EVTIME et l'arrêt d'un process entraîne l'activation automatique du process en
tête de SQS. (Notons que le "temps" est simulé et n’à aucun rapport avec l'écoulement réel du temps
de calcul; les evtimes servent à imposer une relation d'ordre entre les phases de calcul des différents
process).

Voici le squelette de la classe SIMULATION.

SIMSET CLASS SIMULATION;

BEGIN

LINK CLASS PROCESS;

BEGIN
BOOL PROC TERMINATED;...
BOOL PROC IDLE ;...
REAL PROC EVTIME ;...
REF(PROCESS) PROC NEXTEV;...

DETACH;....
END;

{ REF(HEAD) SQS ; }
REF(PROCESS) PROC CURRENT;...
REAL PROC TIME ;...
REF(PROCESS) MAIN ;

PROC HOLD (DT); REAL DT;...

PROC PASSIVATE ;...
PROC WAIT (L); REF(HEAD) L;...
PROC CANCEL(P); REF(PROCESS) P;...

END;
Notons que : [Vau 97]

- SIMULATION est préfixée par SIMSET pour donner accès au traitement de listes.
- Un PROCESS est préfixé par LINK. Un processus peut être à la fois dans SQS et une seule
autre liste.
- -Pour raison de sécurité, la liste SQS est inaccessible à l'usager. Par contre CURRENT est
une fonction qui retourne une référence sur le premier processus de SQS. Par définition, ce
premier processus est celui qui est en exécution.
- TIME retourne CURRENT.EVTIME, ce à dire l'heure courante.
- Le programme peut agir comme un processus et il est désigné par MAIN

7. Conclusion

On a étudié dans ce chapitre le langage de programmation SIMULA, le précurseur des

langages orientés objets. Ce langage offre des possibilités surtout dans le parallélisme et la
simulation.
Dans le chapitre suivant, on va modéliser et simuler le service Pharmacie du le Centre
Hospitalier Universitaire d’Oran (CHUO).
1. Introduction
La pharmacie constitue un du service le plus fréquenté parmi les autres services dans
l'hôpital. La modélisation et la simulation de ce service et de sa gestion permettront la prise de
décision concernant le dimensionnement et le partage des ressources matérielles et humaines.
Le but de ce travail est d'une part d'instancier une partie du modèle de connaissance d'un
hôpital en vue de l'évaluation d'un de ses services et d'autre part de mettre en évidence les
difficultés liées à la modélisation, à la collecte de données significatives et aux outils d'évaluation.

Le service pharmacie, pris en compte, est détaillé dans le paragraphe suivant.

2. Le Service Pharmacie du CHUO

2.1. Définition
La pharmacie représente l’un des services prestataires de l’hôpital. Sa mission réside dans la
fourniture des médicaments pour les patients qui séjournent dans l’hôpital. Dans ce mémoire on
abordera le problème de modélisation et de la simulation de ce service dans le Centre Hospitalier
Universitaire d’Oran.

La pharmacie est composée de différentes sections qui sont présentées par l'organigramme
de la (figure VI.1). La pharmacie est fréquentée par plusieurs services (voir tableau II.1).

2.2. Méthodologie de modélisation

Parmi les différentes méthodologies, on a choisi ASC I (Analyse, Spécification, Conception
et Implémentation). Elle est basée sur la construction de deux classes de modèles : le modèle de
connaissance et les modèles d’action.

2.2.1. Le modèle de connaissance

Le modèle de connaissance décrit la structure et le fonctionnement du système dans un
langage naturel ou graphique et il est composé de trois sous systèmes (physique, logique et
décisionnel).
Figure VI.1 : Organigramme de la Pharmacie
2.2.1.1. Sous Système Physique

Un sous système Physique comprend les entités qui traitent la charge et réalisent les
activités générées.

a- Relation entre services

Le sous système physique de la pharmacie est présenté par les schémas relations entre
services, la matrice des services et l'organigramme ARIS. La légende de cette figure est donnée
dans le tableau II.1.

Figure IV.2 : Relation entre les services de la pharmacie.

b- Matrice des services
La matrice des services de la pharmacie est représentée par la figure VI.3.La légende de
cette figure est donnée dans le tableau II.1.

Figure VI.3 : Matrice de la pharmacie

c- Organigramme

L'organigramme de la pharmacie est donné par la figure VI.4. La légende de cette figure est
donnée dans le tableau II.1.

S.PC: Section de la verrier, Consommable de laboratoire, films et Produits de radiologie.

S.MSMT: Section des Médicaments, Solutés Massifs et Tableau.
R: Responsable.

Figure VI.4 : Organigramme de la pharmacie.

2.2.1.2. Sous Système Logique
Un sous système logique contient les entités qui constituent la charge du système et qui
génèrent ses activités.

Le sous système logique de la pharmacie est présenté par les CPE suivant:

Les Chaînes de Processus Evènementielles (CPE) permettent de représenter l'organigramme

d'entreprise, c'est à dire de représenter les relations entre les objets des vues des données, des
fonctions et des vues organisationnelles et par conséquent de représenter les processus.

L'enchaînement de fonctions dans le sens d'un processus d'entreprise est représenté dans des
chaînes de processus. Dans ces chaînes, il est possible d'indiquer les événements de départ et
d'arrivée pour chaque fonction. Les événements déclenchent les fonctions et sont générés par ces
dernières.

Le symbole graphique de l'événement est un hexagone. La fonction est symbolisée par un

rectangle (figure VI.5).

Fonction Evénement

Figure VI.5 : Fonction et événement

Comme les événements définissent l'état ou la condition qui déclenche une fonction ainsi
que l'état qui en marque l'achèvement, les nœuds de départ et d'arrivée d'une telle CPE sont toujours
des événements. Un événement peut déclencher plusieurs fonctions simultanément et, inversement,
une fonction peut engendrer plusieurs événements. Pour pouvoir représenter ces ramifications et ces
boucles de traitement dans une CPE, le système utilise un connecteur (ou règle) en forme de cercle.
Celui-ci n'est cependant pas un simple connecteur graphique, il définit également les connexions
logiques entre les objets qu'il relie.

La figure VI.6 représente la spécification du service pharmacie par la CPE.

 Figure VI.6 : Chaîne événementielle de la pharmacie.

UF: unité fonctionnelle.

2.2.1.3. Sous Système décisionnel
Un sous système décisionnel décrit les règles de gestion et de pilotage du système.
Le sous système décisionnel de la pharmacie est représenté par la figure VI.7.

Figure VI.7 : Sous système décisionnel de la pharmacie

2.2.2. Le modèle d’Action

Un modèle d’action est une traduction du modèle de connaissance dans un formalisme

mathématique ou dans un langage de programmation.

Le modèle d’action ou de simulation du service pharmacie de Centre Universitaire

Hospitalier d’ORAN est représenté par le modèles Simula. Simula utilise les files d'attente.

2.2.2.1. Modèle de files d’attente

Les schémas des Figures VI.8 et 9 représentent comment employer le modèle des files d’attente
pour représenter un modèle d'action ou de simulation.

Figure VI.8 : Modèle de files d’attente (Déchargement)

Figure VI.9 : Modèle de files d’attente (Distribution)

L’objectif des modèles de simulation réalisés est d’évaluer les critères de performances afin
de dimensionner au mieux les services, d’ajuster le taux d’utilisation des ressources et de diminuer
les temps d’attentes des services et des praticiens dans les services de la Pharmacie.
2.2.2.2. Modèle SIMULA
Le langage SIMULA a prouvé sa capacité d’implantation de différentes catégories de
modèles de simulation. Il inclut des coroutines et des processus de la simulation à événement
discret. De nombreuses classes existantes prolongent des possibilités du langage en gestion de
transactions et en calcul de statistiques. La classe Gpsss fournit les objets de base tels que le service,
le stockage, les notions de transaction et de région statistique, de plus un rapport de simulation est
automatiquement généré. Il peut donc être employé comme en programmation GPSSS mais avec
toutes les capacités d'un langage de simulation orienté objet.

L'activité d'accueil de Service est assurée par un objet facility qui correspond au serveur
unique d'une station. Les statistiques concernant l'attente sont collectées par un objet region. L'objet
storage remplit le triple rôle de serveur multiple, de déchargement, de Saisie, de contrôle et de
distribution. Les délais associés aux durées de traitement (décharge, contrôle, saisie, distribue) sont
exécutés par l'appel à la méthode hold. Les objets utilisés et les résultats sont regroupés dans le
tableauVI.1.

La conception et l'implantation du modèle ont été particulièrement rapides, la manipulation

des objets x de la classe Gpsss étant très facile car basée sur deux méthodes simples Enter_x et
Leave_x. D'autre part, les statistiques fournies automatiquement sont clairement définies et
suffisamment détaillées.

Dans les sous paragraphes suivants, on présente les programmes en Simula de la partie file
d'attente du "déchargement" et de la "distribution" ainsi que les résultats respectifs obtenus.
a- Programme « Déchargement » en SIMULA
transaction CLASS Pharmacie(k);integer k;
BEGIN
d(k):=time;
enter_facility(Service(k));
enter_region(mission(k));
hold(uniform(5,10,u));
enter_storage(Personne(k),s(k)); ! Prise personnel;
hold(uniform(AtPMin(k),AtPMax(k),u)); ! Durée Operation;
leave_storage(Personne(k),s(k)); ! Libérer personnel;
if Nbrm(k) < r(k) then GenerateRequest(k);
enter_storage(Controleur(k),1); ! Prise personnel;
Hold(uniform(ContMin(k),ContMax(k),u)); ! Durée Operation;
leave_storage(Controleur(k),1); ! Libérer personnel;
enter_storage(Saisie(k),1); ! Prise personnel;
hold(uniform(SaisMin(k),SaisMax(k),u)); ! Durée Operation;
leave_storage(Saisie(k),1); ! Libérer personnel;
leave_region(mission(k));
leave_facility(Service(k));
a(k):=a(k)+(time-d(k));
if Nbrm(k) = r(k) then
begin
b(k):=b(k)+1;
hold((b(k)*ArrCam(k))-a(k)-1);
hold(uniform(5,10,u));
r(k):=r(k)+uniform(NbCMin(k),NbCMax(k),u);
end;
END;
Le tableau VI.1 contient les différentes données du modèle par service pour le déchargement.
Les valeurs représentant des données réelles prises du service pharmacie du CHUO pour le
déchargement.
Personnel Décharge Saisie Contrôle Fournisseur
Min Max Min Max Min Max Min Max Min Max Arrivée
Unité Médicament 2 5 45 60 60 120 60 120 1 3 1/mois
Unité Solutés Massifs 1 2 30 60 60 120 30 60 1 3 1/mois
Section Usage Unique 2 5 30 60 60 120 60 120 1 3 1/mois
Section Pansements 3 5 30 60 60 120 60 120 1 3 1/7jours
Section 1 2 30 60 480 960 60 120 1 3 1/3mois
Instrumentations
Section Consommable 2 5 30 45 30 60 30 60 1 3 1/mois
Produit
Le Laboratoire 2 5 30 45 30 60 30 60 1 3 1/mois
Tableau VI.1 : Données du modèle par service (décharge)

L’unité du temps est la minute sauf pour le fournisseur.

b- Résultats en Simula
Les résultats obtenus en Simula pour le déchargement sont données par la figure VI.10.

c :une journée d’exécution

a*b/c probabilité

b :Temps moyen de déchargement

État de Service occupé/libre

a: Nombre d’arrivées dans

le Service

a*b*100/c pourcentage

Capacité du Personnel

Figure VI.10 : Résultats Simula (déchargement)

c- Programme « Distribution » en SIMULA

transaction CLASS Pharmacie(k);integer k;

BEGIN

enter_facility(Service(k));
enter_region(mission(k));
hold(uniform(5,10,u));
enter_storage(Distributeur(k),1); ! Prise personnel;
hold(uniform(ContMin(k),ContMax(k),u)); ! Durée Operation;
enter_storage(Saisie(k),1); ! Prise personnel;
hold(uniform(SaisMin(k),SaisMax(k),u)); ! Durée Operation;
leave_storage(Saisie(k),1); ! Libérer personnel;
leave_storage(Distributeur(k),1); ! Libérer personnel;
leave_region(mission(k));
leave_facility(Service(k));
if Nbr(k) = r(k) then
begin
d(k):=time;a(k):=a(k)+1;
enter_region(temp(k));
hold((a(k)*ArrSar(k))-d(k));
leave_region(temp(k));
hold(uniform(5,10,u));
r(k):=r(k)+uniform(NbsMin(k),NbsMax(k),u);
end;
GenerateRequest(k)

END;
Le tableau VI.2 contient les différentes données du modèle par service pour la distribution.
Les valeurs représentant des données réelles prises du service pharmacie du CHUO pour la
distribution.

Saisie Contrôle Service

Min Max Min Max Min Max arrivée
Unité Médicament 10 15 5 10 8 12 1/7jours
Unité Solutés Massifs 10 15 5 10 8 12 1/7jours
Section Usage Unique 10 15 5 10 3 7 1/15jours
Section Pansements 10 15 5 10 3 7 1/15jours
Section 10 15 5 10 3 7 1/15jours
Instrumentations
Section Consommable 10 15 5 10 3 7 1/15jours
Produit
Le Laboratoire 10 15 5 10 3 7 1/15jours

Tableau VI.2 : Données du modèle par service (distribution)

L’unité du temps est la minute sauf pour l’arrivée du service.

d- Résultats en Simula
Les résultats obtenus en Simula pour le distribution sont données par la figure VI.11.

c :7 jours d’exécution

a*b/c probabilité

b :Temps moyen de distribution

État de Service occupé/libre

a: Nombre de Services arrivés

a*b*100/c pourcentage

Capacité du Personnel

Figure VI.11 : Résultats Simula (distribution)

e- Interprétation des résultats obtenus des deux simulations
a) Déchargement
Le travail de section est compris entre 58% et 99% du temps simulé. Le taux d'occupation
du personnel de décharge est compris entre 8% et 28% celui du contrôle entre 16% et 23% et
celui de la saisie entre 18% et 72%. Il ne s'agit que d'une simulation sur une durée de 8 heures.
Remarquons qu'en saisie, le taux moyen de séjour est très important par rapport à la durée de
décharge et contrôle. Ceci est dû à des créneaux de la saisie trop long de 30 et 960 minutes
(tableau VI.1) et il conduit à la saturation du service lorsque le planning est plein. Le test porte
bien sur des conditions extrêmes de fonctionnement.

b) Distribution
Le travail de section est compris entre 27% et 62% du temps simulé. Le taux d'occupation
du personnel de distribution est compris entre 19% et 45% et celui de la saisie entre 12% et 28%.
Il ne s'agit que d'une simulation sur une durée de 7*8 heures (7 jours). Remarquons que
pour la section Médicament et soluté massif, le temps moyen de séjours est très important par
rapport à la durée des autres sections. Cela est dû au nombre important de services arrivés qui
est de 8 et 12 services (tableau VI.2). Mais on n'oubliera pas que pour ces deux sections, la
distribution se fait d'une manière hebdomadaire et pour cela il faut faire passer plus de 60
services durant les 7 jours.

3. Interface de réalisation et initialisation du Programme SIMULA

Nous avons développé une interface qui nous permet d'initialiser les différents paramètres
du programme Simula et cela pour le programme Décharge et le programme Distribution.

Cette interface a été développé à l'aide de langage JAVA [Jbuilder x] (Figure VI.12 et 13).

Figure VI.12 : Interface pour présenter le Programme en SIMULA

Figure VI.13 : Interface pour initialiser le Programme de Déchargement
Figure VI.14 : Interface pour initialiser le Programme de Distribution

Figure VI.15 : Interface pour Afficher le Programme en SIMULA

4. Conclusion
Dans ce chapitre on a utilisé la méthodologie de modélisation ASCI (Analyse, Spécification,
Conception et Implémentation), pour cela on a utilisé l’outil ARIS pour spécifier le modèle de
connaissance et on a implanté le modèle d’action avec le langage SIMULA.

L’outil d’aide à la décision, réalisé avec la classe Gpsss, nous a fourni des résultats sur le
taux d’utilisation de personnel, contrôle, décharge et distribution du service pharmacie du Centre
Hospitalier Universitaire d’Oran (CHUO).
 CONCLUSION
Dans ce travail on a modélisé et simulé le service pharmacie du Centre Hospitalier
Universitaire d’Oran (CHUO), à l’aide d’une méthodologie de modélisation ASCI (Analyse-
Spécification-Conception-Implimentation), l’outil de modélisation ARIS, le langage de simulation
SIMULA et l’outil d’aide à la décision réalisé avec la classe Gpsss.

Nous avons présenté le service pharmacie et l’utilité du modèle de connaissance spécifié

avec l’outil ARIS, ainsi que le passage de ce modèle vers un modèle d’action ou de simulation
implanté en SIMULA. L’outil d’aide à la décision, réalisé avec la classe Gpsss, nous a fourni des
résultats qui représentent le temps de traitement des secteurs et des personnes rattachés au service
pharmacie ainsi que le temps total après une journée de travail ou plus.

En perspective, plusieurs thèmes de recherches peuvent compléter ce travail :

-La modélisation et la simulation des autres services de l’hôpital,

-Utiliser d’autres outils de modélisation et de simulation,
-Étudier la planification des services de l’hôpital,
-Le pilotage des systèmes hospitaliers.
Références Bibliographiques

[Afr 07] : Africa, "Bien venu au centre hospitalier-universitaire d'Oran « Ben Zarjeb » ", site
consulté le 18/05/2007.
http://chuoran.africa-web.org/

[Ara 00] : L. Aravecchia, E. Bres, Y. Martinez, G. Oliveri, " Quelques définitions d’un système",
JUIN 2000.
http://www.aix-mrs.iufm.fr/formations/filieres/te/data/equipe/groupe_developpement /
auto_2000/ PAGE10/ page10.htm

[Boi 07] : Christian Bois, " Lexique", Mémoire de doctorat en ligne, site consulté le 17/05/2007
http://atoutsic.ouvaton.org/html/post/post_lexique_index.htm

[Bou 06] : A. Boumane, A. Talbi, C. Tahon, D. Bouami, " Identification des compétences requises
en milieu hospitalier : application aux médecins", Luxembourg, du 13 au 15 septembre
2006

[Bri 05] : M. Briquet, J. Colin, D. Gourc et C. Pourcel, " Organisation d’un système hospitalier par
pôles d’activité : modélisation et identification des problèmes de pilotage ", Colloque de
Génie industriel, Besançon, 2005.

[Cha 05] : J. Chauvet, N. Dessommes, N. Durand et A. Quinkal, " Un modèle de connaissance pour
le nouvel hôpital d’Estaing ", DESS management, université d’Auvergne, Clermont-
Ferrand, mars 2005.

[Che 76]: P. Chen, "The entity relationship model – Toward a unified view of data". ACM
Transaction on data base system, Vol 1, N° 1, mars 1976.

[Cov 07] : Philippe Coval, RZR, " Lexique ", site consulté le 17/05/2007
http://rzr.online.fr/docs/net3d/lexique.htm

[Cnr 03] : CNRS, "Action Spécifique 63 Gestion Hospitalier Coopérante", Rapport final décembre,
Département STIC, 2003.

[Com 94] : C. Combes, " Un environnement de modélisation pour les systèmes hospitaliers ",
Thèse de Doctorat, Université Blaise Pascal, Clermont-Ferrand, 27 Octobre 1994.

[Cyb 07] : Cyber Sciences, "la science et la technologie pour tous".

http://www.cybersciences.com/Cyber/1.0/1_871_913.asp

[Die 07] : Serge Diebolt, " Le petit lexique des termes de la complexité ", site consulté le
16/05/2007.
http://www.mcxapc.org/static.php?file=lexique.htm&menuID=lexique
[Epm 07] : Ecole Polytechnique Montréal, "La Simulation par évènement discret", chapitre 1,
Cours INF8701, Montréal, Canada, site consulté le 16/05/2007.
http://www.cours.polymtl.ca/if505/Chapitre_1.pdf

[Fén 05]: P. Féniès, J. Chauvet, M. Chabrol et M. Gourgand, "The new Hospital of Estaing
Knowledge Model: an operational tool for strategic management and flow modelling in
a hospital supply chain. International Conference on the Management of Healthcare &
Medical Technology", Aalborg, Denmark. 2005.

[Fie 93] : M. Fieschi, P. Dujols et R. Beuscart, " L'évaluation des systèmes d'information
hospitaliers ", article, Volume 6, 1993.

[Gou 91] : M. Gourgand et P. Kellert, " Conception d’un environnement de modélisation des
systèmes de production ", 3ème congrès international de Génie Industriel, Tours, 1991.

[Gou 94] : M. Gourgrand, C. Combes, "Un Environnement de modélisation pour les systèmes
hospitaliers ", université de Clermont-Ferrand 2, Clermont-Ferrand, France ,1994.
http://cat.inist.fr/?aModele=afficheN&cpsidt=167168

[Gou 05] : M. Gourgand, M. Chabrol, P. Féniès et N. Tchernev, " Un environnement de

modélisation pour le système d’information de la supply chain : application au Nouvel
Hôpital d’Estaing", Inforsid, Grenoble, mai 2005.

[Gre 00]: P. Green et M. Roseman, " Modelling: An ontological evaluation", In Information

systems, ated process, vol 25, mars 2000.

[Ids 00] : IDS Scheer"ARIS Méthode ", Logiciel ARIS 5, Article, Version 5, Edition septembre
2000.

[Jeb 05]: A. Jebali, " Vers un outil d’aide à la planification et l’ordonnancement des ressources
dans les services de soins ", Thèse en génie industriel, INPG, Grenoble, 2004.

[Lad 05] : P. Ladet, "Les systèmes de production de soins : complexité et incertain ", quelles
réponses ?
Workshop et école intégrée : MHOSI, Hammamet, Tunisie, 24-26 avril 2005.

[Lar 05] : Larousse Dictionnaire de Français, Edition spéciale Algérie, Edition 2005.

[Meb 05]: F. Mebrek, M. Gourgand et A. Tanguy, «Hospital logistic modelling and simulation case
study: brancardage ", ESM05, Porto, Portugal, 24-26 october 2005.

[Meb 06] : F. Mebrek, A. Tanguy, " Modélisation et Simulation à évènements discrets du pôle
imagerie d’u hôpital moderne ", article, 6e Conférence Francophone de Modélisation et
SIMulation - MOSIM’06 - du 3 au 5 avril 2006 – Rabat- Maroc « Modélisation,
Optimisation et Simulation des Systèmes : Défis et Opportunités ».

[Moh 07] : Christoph Mohn, " Définitions en physique/chimie ", Lycos, site consulté le 16/05/2007
http://membres.lycos.fr/machineavapeur/Lexique/lexique.htm
[Pro 07] : Serge. Prouteau, " Quelques définitions simples pour des notions parfois compliquées... ",
Arts plastiques, site consulté le 17/05/2007.
http://www.ac-reunion.fr/pedagogie/artsplastiques/glossaire/artpla-m.htm

[Rés O7] : Réseau d’Activités à Distance, "Glossaire des NTCI", France, site consulté le
17/05/2007 http://rad2000.free.fr/glosntci.htm

[Rom 07]: Cécile Romeyer, Isabelle Bongiovanni "Les systèmes d’information hospitalier, vecteur
de
changement organisationnel", Montpelier, site consulté le 18/05/2007
http://www.aim2000.univ-montp2.fr/pdf/Romeyer.pdf

[She 02]: A.W. Sheer, "ARIS - Business Process Modelling ", Springer, 2002.

[Str 07] : Stratégies & Succès, " Lexique ", site consulté le 17/05/2007
http://www.strategiesetsucces.be/fr/Glossaire/glossaire.asp#m

[Sun 07]: Sun Software Information & Technology Exchange, Sun SITE offre des ressources a
l'echelle mondiale pour l'elaboration de programmes preuniversitaires en ligne, site
consulté le 17/05/2007.
http://sunsite.queensu.ca/rmc/BUS204/Finance/pages/glossaire.html

[Tou 91] : Laurent TOUTAIN, " SAMSON: Un simulateur pour systèmes répartis et temps réel ",
Thèse de doctorat de l’université du Havre, 1991.

[Vau 97] : J.G.Vaucher, " Introduction à simula ", Montréal, Canada, 1997.
http://www.iro.umontreal.ca/~vaucher/Simula/Simula.intro.html

[Vil 04] : Pablo Villanueva, " Modélisation d'un processus de Gestion des commandes sur SAP
R/3:
méthodes ARIS Tool et OSSAD ", Université de Lausanne, Ecole des hautes études
commerciales, 2004.

[Vis 07] : Vision du Web.Com, " Dictionnaire informatique", site consulté le 17/05/2007
http://www.visionduweb.com/index.php4

[Wk1 07] : Wikipédia, "Système ", site consulté le 16/05/2007.

http://fr.wikipedia.org/wiki/Syst%C3%A8me

[Wk2 07] : Wikipédia, "Modèle (économie) ", site consulté le 16/05/2007.

http://fr.wikipedia.org/wiki/Mod%C3%A8le_%28%C3%A9conomie%29

[You 07] : Young Malcom, "Définition des termes techniques ", Web Création, glossaire, site
consulté le 17/05/2007.
http://www.raphpell.freesurf.fr/CreationWeb/index.php?page=20
Programme SIMULA
Le programme en SIMULA de la Distribution est le suivant :

% Simulation de Service Pharmacie De CHUOran

%********************************************
BEGIN
EXTERNAL CLASS gpsss;
gpsss BEGIN

procedure GenerateRequest(k);integer k;
BEGIN real p;
NbG:=NbG+1;
Nbr(k):= Nbr(k)+1;
p:=uniform(5,10,u);
ACTIVATE NEW Pharmacie(k) AT p;
END;

transaction CLASS Pharmacie(k);integer k;

BEGIN
enter_facility(Service(k));
enter_region(mission(k));
hold(uniform(5,10,u));
enter_storage(Distributeur(k),1);
hold(uniform(ContMin(k),ContMax(k),u));
enter_storage(Saisie(k),1);
hold(uniform(SaisMin(k),SaisMax(k),u));
leave_storage(Saisie(k),1);
leave_storage(Distributeur(k),1);
leave_region(mission(k));
leave_facility(Service(k));
if Nbr(k) = r(k) then
begin
d(k):=time;a(k):=a(k)+1;
enter_region(temp(k));
hold((a(k)*ArrSar(k))-d(k));
leave_region(temp(k));
hold(uniform(5,10,u));
r(k):=r(k)+uniform(NbsMin(k),NbsMax(k),u);
end;
GenerateRequest(k)
END;

% -Declaration:
REAL array SaisMin,SaisMax,ArrSar,ContMin,ContMax(1:7);
TEXT array Section(1:7);
INTEGER array Nbr,Nbs,NbsMin,NbsMax,r,d,a(1:7);
INTEGER nbG,k;
REF(Facility) array Service(1:7);
REF(storage) array Distributeur,Saisie(1:7);
REF(region) array mission,temp(1:7);

% -Initialisation:
SaisMin(1):=10;SaisMax(1):=15;
ArrSar(1):=1*480;Nbs(1):=uniform(08,12,u);
ContMin(1):=5;ContMax(1):=10;
Section(1):-"Medicament";NbsMin(1):=08;NbsMax(1):=12;
SaisMin(2):=10;SaisMax(2):=15;
ArrSar(2):=1*480;Nbs(2):=uniform(08,12,u);
ContMin(2):=5;ContMax(2):=10;
Section(2):-"Solutes Massifs";NbsMin(2):=08;NbsMax(2):=12;
SaisMin(3):=10;SaisMax(3):=15;
 ArrSar(3):=1*480;Nbs(3):=uniform(03,07,u);
ContMin(3):=5;ContMax(3):=10;
Section(3):-"Usage Unique";NbsMin(3):=03;NbsMax(3):=07;
SaisMin(4):=10;SaisMax(4):=15;
ArrSar(4):=1*480;Nbs(4):=uniform(03,07,u);
ContMin(4):=5;ContMax(4):=10;
Section(4):-"Pansements";NbsMin(4):=03;NbsMax(4):=07;
SaisMin(5):=10;SaisMax(5):=15;
ArrSar(5):=1*480;Nbs(5):=uniform(03,07,u);
ContMin(5):=5;ContMax(5):=10;
Section(5):-"Instrumentations";NbsMin(5):=03;NbsMax(5):=07;
SaisMin(6):=10;SaisMax(6):=15;
ArrSar(6):=1*480;Nbs(6):=uniform(03,07,u);
ContMin(6):=5;ContMax(6):=10;
Section(6):-"Consommable Produit";NbsMin(6):=03;NbsMax(6):=07;
SaisMin(7):=10;SaisMax(7):=15;
ArrSar(7):=1*480;Nbs(7):=uniform(03,07,u);
ContMin(7):=5;ContMax(7):=10;
Section(7):-"Laboratoire";NbsMin(7):=03;NbsMax(7):=07;

FOR k:=1 STEP 1 UNTIL 7 DO

begin Nbr(k):=0; r(k):=Nbs(k); d(k):=0; a(k):=0;end;

% -Instances:
FOR k:=1 STEP 1 UNTIL 7 DO
BEGIN
Service(k):- New facility("Service"&Section(k));
mission(k) :- NEW region("mission"&Section(k));
temp(k) :- NEW region("TempPerdu"&Section(k));
Saisie(k) :- NEW storage("Sais"&Section(k),1);
Distributeur(k) :- NEW storage("Distributeur"&Section(k),1);
END;

% -Simulation:

% -Generate first transaction:

for k:= 1 step 1 until 7 do
GenerateRequest(k);

% -Start:
Hold(7* 480);
standard_report; Outimage;
Setpos(16);outtext("Nombre service Distribue Arriver"); Outimage;
for k :=1 step 1 until 7 do
begin
setpos(16);outtext(Section(k)&" :");setpos(46);outint(Nbr(k),3);setpos(55);outint(r(k),3);outimage;
end;
Setpos(16);outtext("Nombre Total de Destribution :");setpos(43);Outint(NbG,6); Outimage;

END;

END;
Le programme en SIMULA du Déchargement est le suivant :

% Simulation de Service Pharmacie De CHUOran

%********************************************
BEGIN

EXTERNAL CLASS gpsss;

gpsss BEGIN

procedure GenerateRequest(k);integer k;
BEGIN real p;
NbG:=NbG+1;
Nbrm(k):=Nbrm(k)+1;
p:=uniform(5,10,u);
ACTIVATE NEW Pharmacie(k) AT p;
END;

transaction CLASS Pharmacie(k);integer k;

BEGIN
d(k):=time;
enter_facility(Service(k));
enter_region(mission(k));
hold(uniform(5,10,u));
enter_storage(Personne(k),s(k));
hold(uniform(AtPMin(k),AtPMax(k),u));
leave_storage(Personne(k),s(k));
enter_storage(Controleur(k),1);
Hold(uniform(ContMin(k),ContMax(k),u));
leave_storage(Controleur(k),1);
enter_storage(Saisie(k),1);
hold(uniform(SaisMin(k),SaisMax(k),u));
leave_storage(Saisie(k),1);
leave_region(mission(k));
leave_facility(Service(k));
a(k):=a(k)+(time-d(k));
if Nbrm(k) = r(k) then
begin
b(k):=b(k)+1;
enter_region(temp(k));
hold((b(k)*ArrCam(k))-a(k)-1);
leave_region(temp(k));
hold(uniform(5,10,u));
r(k):=r(k)+uniform(NbCMin(k),NbCMax(k),u);
end;
GenerateRequest(k);
END;

% -Declaration:
INTEGER array Nbrm,NbPMin,NbC,s,NbPMax,NbCMin,NbCMax,a,d,r,b(1:7);
REAL array AtPMin,AtPMax,SaisMin,SaisMax,ArrCam,ContMin,ContMax(1:7);
TEXT array Section(1:7);
INTEGER Nbr,Nbp ,NbG ,l,k;
REF(Facility) array Service(1:7);
REF(storage) array personne,controleur,Saisie(1:7);
REF(region) array mission,temp(1:7);
% -Initialisation:
NbPMin(1):=02;NbPMax(1):=05;AtPMin(1):=45;
AtPMax(1):=60;SaisMin(1):=60;SaisMax(1):=120;
ContMin(1):=60;ContMax(1):=120;
ArrCam(1):=1*480;NbC(1):=uniform(1,3,u);Section(1):-"Medicament";
NbCMin(1):=1;NbCMax(1):=3;
NbPMin(2):=01;NbPMax(2):=02;AtPMin(2):=30;
AtPMax(2):=60;SaisMin(2):=60;SaisMax(2):=120;

ContMin(2):=30;ContMax(2):=60;
ArrCam(2):=1*480;NbC(2):=uniform(1,3,u);Section(2):-"Solutes Massifs";
NbCMin(2):=1;NbCMax(2):=3;
NbPMin(3):=02;NbPMax(3):=05;AtPMin(3):=30;
AtPMax(3):=60;SaisMin(3):=60;SaisMax(3):=120;
ContMin(3):=60;ContMax(3):=120;
ArrCam(3):=1*480;NbC(3):=uniform(1,3,u);Section(3):-"Usage Unique";
NbCMin(3):=1;NbCMax(3):=3;
NbPMin(4):=03;NbPMax(4):=05;AtPMin(4):=30;
AtPMax(4):=60;SaisMin(4):=60;SaisMax(4):=120;
ContMin(4):=60;ContMax(4):=120;
ArrCam(4):=1*480;NbC(4):=uniform(1,3,u);Section(4):-"Pansements";
NbCMin(4):=1;NbCMax(4):=3;
NbPMin(5):=01;NbPMax(5):=02;AtPMin(5):=30;
AtPMax(5):=60;SaisMin(5):=480;SaisMax(5):=960;
ContMin(5):=60;ContMax(5):=120;
ArrCam(5):=1*480;NbC(5):=uniform(1,3,u);Section(5):-"Instrumentations";
NbCMin(5):=1;NbCMax(5):=3;
NbPMin(6):=02;NbPMax(6):=05;AtPMin(6):=30;
AtPMax(6):=45;SaisMin(6):=30;SaisMax(6):=60;
ContMin(6):=30;ContMax(6):=60;
ArrCam(6):=1*480;NbC(6):=uniform(1,3,u);Section(6):-"Consommable Produit";
NbCMin(6):=1;NbCMax(6):=3;
NbPMin(7):=02;NbPMax(7):=05;AtPMin(7):=30;
AtPMax(7):=45;SaisMin(7):=30;SaisMax(7):=60;
ContMin(7):=30;ContMax(7):=60;
ArrCam(7):=1*480;NbC(7):=uniform(1,3,u);Section(7):-"Laboratoire";
NbCMin(7):=1;NbCMax(7):=3;
for k:=1 step 1 until 7 do Nbrm(k):=0;
for k:= 1 step 1 until 7 do
begin s(k):=uniform(NbPMin(k),NbPMax(k),u);d(k):=0;a(k):=0;b(k):=0;r(k):=NbC(k);end;

% -Instances:

for k:= 1 step 1 until 7 do

begin
Service(k) :- New facility("Service "&Section(k));
personne (k):- NEW storage("Person"&Section(k),s(k));
Controleur(k) :- NEW storage("Control"&Section(k),1);
Saisie(k) :- NEW storage("Saisie"&Section(k),1);
mission(k) :- NEW region("mission"&Section(k));
temp(k) :- NEW region("TempPerdu"&Section(k));
end;
% -Simulation:

% -Generate first transaction:

for k:= 1 step 1 until 7 do
GenerateRequest(k);

% -Start:
Hold(1*480);
standard_report; Outimage;
Setpos(16);outtext("Nombre services Decharge Arrivee"); Outimage;
for l :=1 step 1 until 7 do
begin
setpos(16);outtext(Section(l)&" :");setpos(46);outint(Nbrm(l),3);setpos(55);outint(r(l),3);outimage;
end;
Setpos(16);outtext("Nombre Total de Dechargement :");setpos(43);Outint(NbG,6); Outimage;

END;

END;