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 :

M r BELKADI Khaled Mme NOUREDDINE Myriam

Mr RAHAL Sid Ahmed

Promotion 2006/2007

Remerciements

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 «AllahAllahAllahAllah »»»» 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.

C C C C

DédicaceDédicaceDédicaceDédicacessss 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édicaceDédicaceDédicaceDédicacessss

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

J

SommaireIntroduction 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

5. Simulation…………………...................................................................... 8

6. Conclusion ………...……………….…………………………………… 9

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

Au niveau de la direction générale du CHU d'Oran (1 ère é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-

TRAUMATOLOGIE CCF CHU 65 05/19 Dimanche

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

ADDA BENAOUDA 19 02/26 Samedi

33 NEUROPHYSIOLOGIE NEUROPH CHU - - - 34 GYNECOLOGIE OBSTETRIQUE MATER CHU 136 06/20 Mercredi 35 CLINIQUE DE GYNECOLOGIE NOUAR

FADELA AMONDIER - 02/16 Mardi

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) 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-

TRAUMATOLOGIE CCF CHU 65 05/19 Dimanche

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

ADDA BENAOUDA 19 02/26 Samedi

33 NEUROPHYSIOLOGIE NEUROPH CHU - - - 34 GYNECOLOGIE OBSTETRIQUE MATER CHU 136 06/20 Mercredi 35 CLINIQUE DE GYNECOLOGIE NOUAR

FADELA AMONDIER - 02/16 Mardi

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

PATHOLOGIE ANAPA CHU - 04/18 -

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

MOLECULAIRE LAB GBM CHU - - -

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 (Ar chitecture 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'Ar chitecture 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) : SIMU lation 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).

EvénementFonction

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.

Tableau VI.1 : Données du modèle par service (décharge) L’unité du temps est la minute sauf pour le fournisseur.

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 Instrumentations

1 2 30 60 480 960 60 120 1 3 1/3mois

Section Consommable Produit

2 5 30 45 30 60 30 60 1 3 1/mois

Le Laboratoire 2 5 30 45 30 60 30 60 1 3 1/mois

b- Résultats en Simula

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

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

c :une journée d’exécution

a*b/c probabilité

a: Nombre d’arrivées dans le Service

État de Service occupé/libre

b :Temps moyen de déchargement

a*b*100/c pourcentage

Capacité du Personnel

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.

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.

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 Instrumentations

10 15 5 10 3 7 1/15jours

Section Consommable Produit

10 15 5 10 3 7 1/15jours

Le Laboratoire 10 15 5 10 3 7 1/15jours

d- Résultats en Simula

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

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

c :7 jours d’exécution

a: Nombre de Services arrivés

b :Temps moyen de distribution

a*b/c probabilité

État de Service occupé/libre

Capacité du Personnel

a*b*100/c pourcentage

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;