Моделирование работы больничной палаты

Тип работы:
Курсовая
Предмет:
Программирование


Узнать стоимость

Детальная информация о работе

Выдержка из работы

ФГОУ СПО «Волгоградский технологический коледж»

КУРСОВОЙ ПРОЕКТ

Моделирование работы больничной палаты

Разработчик А.И. Сухинин

Рук. проекта А.А. Теткин

Содержание

1. Введение

2. Моделирование систем массового обслуживания

2.1 Структура и параметры эффективности и качества функционирования СМО

2.2 Классификация СМО и их основные элементы

2.3 Процесс имитационного моделирования

3. Описание системы

3.1 Классы и объекты

3.2 События и методы

4. Программная реализация алгоритма

5. Анализ результатов работы программы

Заключение

Список использованной литературы

1. Введение

Во многих областях практической деятельности человека мы сталкиваемся с необходимостью пребывания в состоянии ожидания. Подобные ситуации возникают в очередях в билетных кассах, в крупных аэропортах, при ожидании обслуживающим персоналом самолетов разрешения на взлет или посадку, на телефонных станциях в ожидании освобождения линии абонента, в ремонтных цехах в ожидании ремонта станков и оборудования, на складах снабженческо-сбытовых организаций в ожидании разгрузки или погрузки транспортных средств. Во всех перечисленных случаях имеем дело с массовостью и обслуживанием. Изучением таких ситуаций занимается теория массового обслуживания.

В теории систем массового обслуживания (в дальнейшем просто — CMО) обслуживаемый объект называют требованием. В общем случае под требованием обычно понимают запрос на удовлетворение некоторой потребности, например, обслуживание автомобиля на заправочной станции, разговор с абонентом, посадка самолета, покупка билета, получение материалов на складе и т. д

На первичное развитие теории массового обслуживания оказали особое влияние работы датского ученого А. К. Эрланга (1878−1929).

Теория массового обслуживания — область прикладной математики, занимающаяся анализом процессов в системах производства, обслуживания, управления, в которых однородные события повторяются многократно, например, на предприятиях бытового обслуживания; в системах приема, переработки и передачи информации; автоматических линиях производства и др.

Задача теории массового обслуживания — установить зависимость результирующих показателей работы системы массового обслуживания (вероятности того, что заявка будет обслужена; математического ожидания числа обслуженных заявок и т. д.) от входных показателей (количества каналов в системе, параметров входящего потока заявок и т. д.). Результирующими показателями или интересующими нас характеристиками СМО являются — показатели эффективности СМО, которые описывают способна ли данная система справляться с потоком заявок.

В теории СМО рассматриваются такие случаи, когда поступление требований происходит через случайные промежутки времени, а продолжительность обслуживания требований не является постоянной, т. е. носит случайный характер. В силу этих причин одним из основных методов математического описания СМО является аппарат теории случайных процессов.

Основной задачей теории СМО является изучение режима функционирования обслуживающей системы и исследование явлений, возникающих в процессе обслуживания. Так, одной из характеристик обслуживающей системы является время пребывания требования в очереди. Очевидно, что это время можно сократить за счет увеличения количества обслуживающих устройств. Однако каждое дополнительное устройство требует определенных материальных затрат, при этом увеличивается время бездействия обслуживающего устройства из-за отсутствия требований на обслуживание, что также является негативным явлением. Следовательно, в теории СМО возникают задачи оптимизации: каким образом достичь определенного уровня обслуживания (максимального сокращения очереди или потерь требований) при минимальных затратах, связанных с простоем обслуживающих устройств.

Имитационное моделирование реализуются программно с использованием различных языков, как универсальных — БЕЙСИК, РАСКАЛЬ, С, С++ и т. д., так и специализированных, предназначенных для построения имитационных моделей — СИМСКРИПТ, СТАМ/КЛАСС, GPSS, SLAM, Pilgrim и др.

Целью данной курсовой работы является разработка имитационной модели с регулярным входным потоком, отсутствующей очередью и естественным отсчетом времени т. е моделирование работы больничной палаты. Основой для разработки модели в данной курсовой работе является метод имитационного моделирования. Так же курсовая работа предполагает создание программы на языке C++, обеспечивающей ввод исходной информации, ее обработку, реализацию алгоритма имитации процесса и выдачу необходимой информации.

имитационная модель программа

2. Моделирование систем массового обслуживания

2. 1 Структура и параметры эффективности и качества функционирования СМО

Многие экономические задачи связаны с системами массового обслуживания, т. е. такими системами, в которых, с одной стороны, возникают массовые запросы (требования) на выполнение каких-либо услуг, с другой — происходит удовлетворение этих запросов. СМО включает в себя следующие элементы: источник требований, входящий поток требований, очередь, обслуживающие устройства (каналы обслуживания), выходящий поток требований. Исследованием таких систем занимается теория массового обслуживания.

Средства, обслуживающие требования, называются обслуживающими устройствами или каналами обслуживания. Например, к ним относятся заправочные устройства на АЗС, каналы телефонной связи, посадочные полосы, мастера-ремонтники, билетные кассиры, погрузочно-разгрузочные точки на базах и складах.

Методами теории массового обслуживания могут быть решены многие задачи исследования процессов, происходящих в экономике. Так, в организации торговли эти методы позволяют определить оптимальное количество торговых точек данного профиля, численность продавцов, частоту завоза товаров и другие параметры. Другим характерным примером систем массового обслуживания могут служить заправочные станции, и задачи теории массового обслуживания в данном случае сводятся к тому, чтобы установить оптимальное соотношение между числом поступающих на заправочную станцию требований на обслуживание и числом обслуживающих устройств, при котором суммарные расходы на обслуживания и убытки от простоя были бы минимальными. Теория массового обслуживания может найти применение и при расчете площади складских помещений, при этом складская площадь рассматривается как обслуживающее устройство, а прибытие транспортных средств под выгрузку — как требование. Модели теории массового обслуживания применяются также при решении ряда задач организации и нормирования труда, других социально-экономических проблем.

Каждая СМО включает в свою структуру некоторое число обслуживающих устройств, называемых каналами обслуживания (к их числу можно отнести лиц, выполняющих те или иные операции, — кассиров, операторов, менеджеров, и т. п.), обслуживающих некоторый поток заявок (требований), поступающих на ее вход в случайные моменты времени. Обслуживание заявок происходит за неизвестное, обычно случайное время и зависит от множества самых разнообразных факторов. После обслуживания заявки канал освобождается и готов к приему следующей заявки. Случайный характер потока заявок и времени их обслуживания приводит к неравномерности загрузки СМО — перегрузке с образованием очередей заявок или недогрузке — с простаиванием ее каналов. Случайность характера потока заявок и длительности их обслуживания порождает в СМО случайный процесс, для изучения которого необходимы построение и анализ его математической модели. Изучение функционирования СМО упрощается, если случайный процесс является марковским (процессом без последействия, или без памяти), когда работа СМО легко описывается с помощью конечных систем обыкновенных линейных дифференциальных уравнений первого порядка, а в предельном режиме (при достаточно длительном функционировании СМО) посредством конечных систем линейных алгебраических уравнений. В итоге показатели эффективности функционирования СМО выражаются через параметры СМО, потока заявок и дисциплины.

Из теории известно, чтобы случайный процесс являлся Марковским, необходимо и достаточно, чтобы все потоки событий (потоки заявок, потоки обслуживаний заявок и др.), под воздействием которых происходят переходы системы из состояния в состояние, являлись пуассоновским, т. е. обладали свойствами последствия (для любых двух непересекающихся промежутков времени число событий, наступающих за один из них, не зависит от числа событий, наступающих за другой) и ординарности (вероятность наступления за элементарным, или малый, промежуток времени более одного события пренебрежимо мала по сравнению с вероятностью наступления за этот промежуток времени одного события). Для простейшего пуассоновского потока случайная величина Т (промежуток времени между двумя соседними событиями) распределена по показательному закону, представляя собой плотность ее распределения или дифференциальную функцию распределения.

Если же в СМО характер потоков отличен от пуассоновского, то ее характеристики эффективности можно определить приближенно с помощью Марковской теории массового обслуживания, причем тем точнее, чем сложнее СМО, чем больше в ней каналов обслуживания. В большинстве случаев для обоснованных рекомендаций по практическому управлению СМО совсем не требует знаний точных ее характеристик, вполне достаточно иметь их приближенные значения.

Каждая СМО в зависимости от своих параметров обладает определенной эффективностью функционирования.

Эффективность функционирования СМО характеризуют три основные группы показателей:

1. Эффективность использования СМО — абсолютная или относительная пропускные способности, средняя продолжительность периода занятости СМО, коэффициент использования СМО, коэффициент не использования СМО;

2. Качество обслуживания заявок- среднее время (среднее число заявок, закон распределения) ожидания заявки в очереди или пребывания заявки в СМО; вероятность того, что поступившая заявка немедленно примется к исполнению;

3. Эффективность функционирования пары CМО потребитель, причем под потребителем понимается как совокупность заявок или их некоторый источник (например, средний доход, приносимый СМО за единицу времени эксплуатации, и др).

2.2 Классификация СМО и их основные элементы

СМО классифицируются на разные группы в зависимости от состава и от времени пребывания в очереди до начала обслуживания, и от дисциплины обслуживания требований.

По составу СМО бывают одноканальные (с одним обслуживающим устройством) и многоканальные (с большим числом обслуживающих устройств). Многоканальные системы могут состоять из обслуживающих устройств как одинаковой, так и разной производительности.

По времени пребывания требований в очереди до начала обслуживания системы делятся на три группы:

1) с неограниченным временем ожидания (с ожиданием),

2) с отказами;

3) смешанного типа.

В СМО с неограниченным временем ожидания очередное требование, застав все устройства занятыми, становится в очередь и ожидает обслуживания до тех пор, пока одно из устройств не освободится.

В системах с отказами поступившее требование, застав все устройства занятыми, покидает систему. Классическим примером системы с отказами может служить работа автоматической телефонной станции.

В системах смешанного типа поступившее требование, застав все (устройства занятыми, становятся в очередь и ожидают обслуживания в течение ограниченного времени. Не дождавшись обслуживания в установленное время, требование покидает систему.

Кратко рассмотрим особенности функционирования некоторых из этих ситем.

1. СМО с ожиданием характеризуется тем, что в системе из n (n> =1) любая заявка, поступившая в СМО в момент, когда все каналы заняты, становится в очередь и ожидает своего обслуживания, причем любая пришедшая заявка обслужена. Такая система может находится в одном из бесконечного множества состояний: sn(r=1. 2…) -все каналы заняты и в очереди находится r заявок.

2. СМО с ожиданием и ограничением на длину очереди отличается от вышеприведенной тем, что эта система может находиться в одном из n+m+1 состояний. В состояниях s0, s1,…, sn очереди не существует, так как заявок в системе или нет или нет вообще и каналы свободны (s0), или в системе есть несколько I (I=1,n) заявок, которого обслуживает соответствующее (n+1, n+2,…n+r,…, n+m) число заявок и (1,2,…r,…, m) заявок, стоящих в очереди. Заявка, пришедшая на вход СМО в момент времени, когда в очереди стоят уже m заявок, получает отказ и покидает систему необслуженной.

Т. о, многоканальная СМО работает по сути как одноканальная, когда все n каналов работают как один с дисциплиной взаимопомощи, называемой все как один, но с более высокой интенсивностью обслуживания. Граф состояний подобной подобной системы содержит всего два состояния: s0 (s1) — все n каналов свободны (заняты).

Анализ различных видов СМО с взаимопомощью типа все как один показывает, что такая взаимопомощь сокращает среднее время пребывания заявки в системе, но ухудшает ряд других таких характеристик, как вероятность отказа, пропускная способность, средние число заявок в очереди и время ожидания их выполнения. Поэтому для улучшения этих показателей используется изменение дисциплины обслуживания заявок с равномерной взаимопомощью между каналами следующим образом:

· Если заявка поступает в СМО в момент времени, когда все каналы свободны, то все n каналов приступает к ее обслуживанию;

· Если в это время приходит следующая заявка, то часть каналов переключается на ее обслуживание

· Если во время обслуживания этих двух заявок поступает третья заявка, то часть каналов переключается на обслуживание этой третьей заявки, до тех пор, пока каждая заявка, находящаяся в СМО, не окажется под обслуживанием только одного канала. При этом заявка, поступившая в момент занятости всех каналов, в СМО с отказами и равномерной взаимопомощью между каналами, может получить отказ и вынуждена будет покинуть систему необслуженной.

Методы и модели, применяющиеся в теории массового обслуживания, можно условно разделить на аналитические и имитационные.

Аналитические методы теории массового обслуживания позволяют получить характеристики системы как некоторые функции параметров ее функционирования. Благодаря этому появляется возможность проводить качественный анализ влияния отдельных факторов на эффективность работы СМО. Имитационные методы основаны на моделировании процессов массового обслуживания на ЭВМ и применяются, если невозможно применение аналитических моделей.

В настоящее время теоретически наиболее разработаны и удобны в практических приложениях методы решения таких задач массового обслуживания, в которых входящий поток требований является простейшим (пуассоновским).

Для простейшего потока частота поступления требований в систему подчиняется закону Пуассона, т. е. вероятность поступления за время t ровно k требований задается формулой:

Важная характеристика СМО — время обслуживания требований в системе. Время обслуживания одного требования является, как правило, случайной величиной и, следовательно, может быть описано законом распределения. Наибольшее распространение в теории и особенно в практических приложениях получил экспоненциальный закон распределения времени обслуживания. Функция распределения для этого закона имеет вид:

F (t)=1e-µt

Т.е. вероятность того, что время обслуживания не превосходит некоторой величины t, определяется этой формулой, где µ- параметр экспоненциального обслуживания требований в системе, т. е. величина, обратная времени обслуживания tоб:

µ=1/ tоб

Рассмотрим аналитические модели наиболее распространенных СМО с ожиданием, т. е. таких СМО, в которых требования, поступившие в момент, когда все обслуживающие каналы заняты, ставятся в очередь и обслуживаются по мере освобождения каналов.

Общая постановка задачи состоит в следующем. Система имеет n обслуживающих каналов, каждый из которых может одновременно обслуживать только одно требование.

В систему поступает простейший (пауссоновский) поток требований c параметром. Если в момент поступления очередного требования в системе на обслуживании уже находится не меньше n требований (т.е. все каналы заняты), то это требование становится в очередь и ждет начала обслуживания.

В системах с определенной дисциплиной обслуживания поступившее требование, застав все устройства занятыми, в зависимости от своего приоритета, либо обслуживается вне очереди, либо становится в очередь.

Основными элементами СМО являются: входящий поток требований, очередь требований, обслуживающие устройства, (каналы) и выходящий поток требований.

Изучение СМО начинается с анализа входящего потока требований. Входящий поток требований представляет собой совокупность требований, которые поступают в систему и нуждаются в обслуживании. Входящий поток требований изучается с целью установления закономерностей этого потока и дальнейшего улучшения качества обслуживания.

В большинстве случаев входящий поток неуправляем и зависит от ряда случайных факторов. Число требований, поступающих в единицу времени, случайная величина. Случайной величиной является также интервал времени между соседними поступающими требованиями. Однако среднее количество требований, поступивших в единицу времени, и средний интервал времени между соседними поступающими требованиями предполагаются заданными.

Среднее число требований, поступающих в систему обслуживания за единицу времени, называется интенсивностью поступления требований и определяется следующим соотношением:

где Т — среднее значение интервала между поступлением очередных требований.

Для многих реальных процессов поток требований достаточно хорошо описывается законом распределения Пуассона. Такой поток называется простейшим.

Простейший поток обладает такими важными свойствами:

1) Свойством стационарности, которое выражает неизменность вероятностного режима потока по времени. Это значит, что число требований, поступающих в систему в равные промежутки времени, в среднем должно быть постоянным. Например, число вагонов, поступающих под погрузку в среднем в сутки должно быть одинаковым для различных периодов времени, к примеру, в начале и в конце декады.

2) Отсутствия последействия, которое обуславливает взаимную независимость поступления того или иного числа требований на обслуживание в непересекающиеся промежутки времени. Это значит, что число требований, поступающих в данный отрезок времени, не зависит от числа требований, обслуженных в предыдущем промежутке времени. Например, число автомобилей, прибывших за материалами в десятый день месяца, не зависит от числа автомобилей, обслуженных в четвертый или любой другой предыдущий день данного месяца.

3) Свойством ординарности, которое выражает практическую невозможность одновременного поступления двух или более требований (вероятность такого события неизмеримо мала по отношению к рассматриваемому промежутку времени, когда последний устремляют к нулю).

При простейшем потоке требований распределение требований, поступающих в систему подчиняются закону распределения Пуассона:

вероятность того, что в обслуживающую систему за время t поступит именно k требований:

где. — среднее число требований, поступивших на обслуживание в единицу времени.

На практике условия простейшего потока не всегда строго выполняются. Часто имеет место нестационарность процесса (в различные часы дня и различные дни месяца поток требований может меняться, он может быть интенсивнее утром или в последние дни месяца). Существует также наличие последействия, когда количество требований на отпуск товаров в конце месяца зависит от их удовлетворения в начале месяца. Наблюдается и явление неоднородности, когда несколько клиентов одновременно пребывают на склад за материалами. Однако в целом пуассоновский закон распределения с достаточно высоким приближением отражает многие процессы массового обслуживания.

Кроме того, наличие пуассоновского потока требований можно определить статистической обработкой данных о поступлении требований на обслуживание. Одним из признаков закона распределения Пуассона является равенство математического ожидания случайной величины и дисперсии этой же величины, т. е.

Одной из важнейших характеристик обслуживающих устройств, которая определяет пропускную способность всей системы, является время обслуживания.

Время обслуживания одного требования () — случайная величина, которая может изменятся в большом диапазоне. Она зависит от стабильности работы самих обслуживающих устройств, так и от различных параметров, поступающих в систему, требований (к примеру, различной грузоподъемности транспортных средств, поступающих под погрузку или выгрузку.

Случайная величина полностью характеризуется законом распределения, который определяется на основе статистических испытаний.

На практике чаще всего принимают гипотезу о показательном законе распределения времени обслуживания.

Показательный закон распределения времени обслуживания имеет место тогда, когда плотность распределения резко убывает с возрастанием времени t. Например, когда основная масса требований обслуживается быстро, а продолжительное обслуживание встречается редко. Наличие показательного закона распределения времени обслуживания устанавливается на основе статистических наблюдений.

При показательном законе распределения времени обслуживания вероятность события, что время обслуживания продлиться не более чем t, равна:

где v — интенсивность обслуживания одного требования одним обслуживающим устройством, которая определяется из соотношения:

,(1)

где — среднее время обслуживания одного требования одним обслуживающим устройством.

Следует заметить, что если закон распределения времени обслуживания показательный, то при наличии нескольких обслуживающих устройств одинаковой мощности закон распределения времени обслуживания несколькими устройствами будет также показательным:

где n — количество обслуживающих устройств.

Важным параметром СМО является коэффициент загрузки, который определяется как отношение интенсивности поступления требований к интенсивности обслуживания v.

(2)

где a — коэффициент загрузки; - интенсивность поступления требований в систему; v — интенсивность обслуживания одного требования одним обслуживающим устройством.

Из (1) и (2) получаем, что

Учитывая, что — интенсивность поступления требований в систему в единицу времени, произведение показывает количество требований, поступающих в систему обслуживания за среднее время обслуживания одного требования одним устройством.

Для СМО с ожиданием количество обслуживаемых устройств п должно быть строго больше коэффициента загрузки (требование установившегося или стационарного режима работы СМО) :.

В противном случае число поступающих требований будет больше суммарной производительности всех обслуживающих устройств, и очередь будет неограниченно расти.

Для СМО с отказами и смешанного типа это условие может быть ослаблено, для эффективной работы этих типов СМО достаточно потребовать, чтобы минимальное количество обслуживаемых устройств n было не меньше коэффициента загрузки:

2. 3 Процесс имитационного моделирования

Как уже было отмечено ранее, процесс последовательной разработки имитационной модели начинается с создания простой модели, которая затем постепенно усложняется в соответствии с требованиями, предъявляемыми решаемой проблемой. В процессе имитационного моделирования можно выделить следующие основные этапы:

1. Формирование проблемы: описание исследуемой проблемы и определение целей исследования.

2. Разработка модели: логико-математическое описание моделируемой системы в соответствии с формулировкой проблемы.

3. Подготовка данных: идентификация, спецификация и сбор данных.

4. Трансляция модели: перевод модели на язык, приемлемый для используемой ЭВМ.

5. Верификация: установление правильности машинных программ.

6. Валидация: оценка требуемой точности и соответствие имитационной модели реальной системе.

7. Стратегическое и тактическое планирование: определение условий проведения машинного эксперимента с имитационной моделью.

8. Экспериментирование: прогон имитационной модели на ЭВМ для получения требуемой информации.

9. Анализ результатов: изучение результатов имитационного эксперимента для подготовки выводов и рекомендаций по решению проблемы.

10. Реализация и документирование: реализация рекомендаций, полученных на основе имитации, составление документации по модели и ее использованию.

Рассмотрим основные этапы имитационного моделирования. Первой задачей имитационного исследования является точное определение проблемы и детальная формулировка целей исследования. Как правило, определение проблемы является непрерывным процессом, который обычно осуществляется в течении всего исследования. Оно пересматривается по мере более глубокого понимания исследуемой проблемы и возникновения новых ее аспектов.

Как только сформулировано начальное определение проблемы, начинается этап построения модели исследуемой системы. Модель включает статистическое и динамическое описание системы. В статистическом описании определяются элементы системы и их характеристики, а в динамическом- взаимодействие элементов системы, в результате которых происходит изменение ее состояния во времени.

Процесс формирования модели во многом является искусством. Разработчик модели должен понять структуру системы, выявить правила ее функционирования и суметь выделить в них самое существенное, исключив ненужные детали. Модель должна быть простой для понимания и в то же время достаточно сложной, чтобы реалистично отображать характерные черты реальной системы. Наиболее важными являются принимаемые разработчиком решения относительно того, верны ли принятые упрощения и допущения, какие элементы и взаимодействия между ними должны быть включены в модель. Уровень детализации модели зависит от целей ее создания. Необходимо рассматривать только те элементы, которые имеют существенное значение для решения исследуемой проблемы. Как на этапе формирования проблемы, так и на этапе моделирования необходимо тесное взаимодействие между разработчиком модели и ее пользователями. Кроме того, тесное взаимодействие на этапах формулирования проблемы и разработки модели создает у пользователя уверенность в правильности модели, поэтому помогает обеспечить успешную реализацию результатов имитационного исследования.

На этапе разработки модели определяются требования к входным данным. Некоторые из этих данных могут уже быть в распоряжении разработчика модели, в то время как для сбора других потребуется время и усилия. Обычно значение таких входных данных задаются на основе некоторых гипотез или предварительного анализа. В некоторых случаях точные значения одного (и более) входных параметров оказывают небольшое влияние на результаты прогонов модели. Чувствительность получаемых результатов к изменению входных данных может быть оценена путем проведения серии имитационных прогонов для различных значений входных параметров. Имитационная модель, следовательно, может использоваться для уменьшения затрат времени и средств на уточнение входных данных. После того как разработана модель и собраны начальные входные данные, следующей задачей является перевод модели в форму, доступную для компьютера.

На этапах верификации и валидации осуществляется оценка функционирования имитационной модели. На этапе верификации определяется, соответствует ли запрограммированная для ЭВМ модель замыслу разработчика. Это обычно осуществляется путем ручной проверки вычисления, а также может быть использован и ряд статистических методов.

Установление адекватности имитационной модели исследуемой системы осуществляется на этапе валидации. Валидация модели обычно выполняется на различных уровнях. Специальные методы валидации включают установление адекватности путем использования постоянных значений всех параметров имитационной модели или путем оценивания чувствительности выходов к изменению значений входных данных. В процессе валидации сравнение должно осуществляться на основе анализа как реальных, так и экспериментальных данных о функционировании системы.

Условия проведения машинных прогонов модели определяется на этапах стратегического и тактического планирования. Задача стратегического планирования заключается в разработке эффективного плана эксперимента, в результате которого выясняется взаимосвязь между управляемыми переменными, либо находится комбинация значений управляемых переменных, минимизация или максимизация имитационной модели. В тактическом планировании в отличии от стратегического решается вопрос о том, как в рамках плана эксперимента провести каждый имитационный прогон, чтобы получить наибольшее количество информации из выходных данных. Важное место в тактическом планировании занимают определение условий имитационных прогонов и методы снижения дисперсии среднего значения отклика модели.

Следующие этапы в процессе имитационного исследования- проведение машинного эксперимента и анализ результатов- включают прогон имитационной модели на ЭВМ и интерпретацию полученных выходных данных. Последним этапом имитационного исследования является реализация полученных решений и документирование имитационной модели и ее использование. Ни одни из имитационных проектов не должен считаться законченным до тех пор, пока их результаты не были использованы в процессе принятия решений. Успех реализации во многом зависит от того, насколько правильно разработчик модели выполнил все предыдущие этапы процессов имитационного исследования. Если разработчик и пользователь работали в тесном контакте и достигли взаимопонимания при разработке модели и ее исследовании, то результат проекта скорее всего будет успешно внедряться. Если же между ними не было тесной взаимосвязи, то, несмотря на элегантность и адекватность имитационного моделирования, сложно будет разработать эффективные рекомендации.

Вышеперечисленные этапы редко выполняются в строго заданной последовательности, начиная с определения проблемы и кончая документированием. В ходе имитационного моделирования могут быть сбои в прогонах модели, ошибочные допущения, от которых в дальнейшем приходится отказываться, переориентировки целей исследования, повторные оценки и перестройки модели. Такой процесс позволяет разработать имитационную модель, которая дает верную оценку альтернатив и облегчает процесс принятия решений.

3. Описание системы

В среднем за день п палату больницы поступают двое больных. Здоровье человека оценивается по определенной шкале. Каждый больной проходит тест, результаты которого равномерно распределены на интервале от 30 до 44 баллов. Когда в палате нет свободных мест, больные с оценкой выше 41 баллов на лечение не принимаются. Всего н палате 25 мест. Больной выписывается из палаты, когда его оценка становится выше 49 баллов. Оценка больного меняется в течение суток на величину, равномерно распределенную на интервале от -0,2 до 1,2 баллов. Когда в палате нет свободных мест, но поступает потенциальный больной, из нее выписывается б0льной, оценка которого равна или выше 47 баллов. Требуется оценить следующие величины: среднее время пребывания больного в палате, загрузку палаты, число отказов в лечении, число выписанных досрочно.

3.1 Классы и объекты

Описанная система является довольно простой, тем не менее, объектное проектирование имитационной программы следует провести со всей серьезностью и тщательностью. Прежде всего, не вызывает сомнений необходимость введения класса Палата, который будет представлен в программе ровно одним объектом. Этот объект должен содержать до 25 пациентов, каким-то образом представленных в классе Палата. Нужно учесть, какую информацию о каждом пациенте мы должны хранить в процессе моделирования. Это, во-первых, количество дней, проведенных больным в палате (их «возраст»), во-вторых, текущая оценка его состояния в баллах. Такой объем информации представляется вполне достаточным для того, чтобы организовать для пациента отдельный класс. Альтернативой этому решению было бы описание в качестве полей данных класса Палата двух массивов или списков, в которых хранятся, соответственно, «возраст» больных и их оценки. Однако такой вариант организации программы не в полной мере соответствует идеологии объектного программирования. В самом деле, количество пунктов информации о пациенте, подлежащей отслеживанию, может изменяться. В первом случае эти изменения будут инкапсулироваться в протоколе класса Пациент, а во втором случае придется модифицировать класс Палата, вводя в него обработку все новых и новых массивов. Кроме того, будет трудно при необходимости отслеживать изменения состояния отдельных пациентов с течением времени.

Количество объектов класса Пациент является переменной величиной, и придется хранить их в массиве или связном списке. Остановимся на связном списке как на более универсальном решении, так как для массива нужно задавать размер, который в большинстве случаев неизвестен. Можно сказать, что в данной задаче имеется естественное ограничение -- 25, но это скорее исключение, чем правило. Дело в том, что описанная система обладает одной существенной особенно- стью -- в ней отсутствует очередь. А если очередь существует и ее длина не огра- ничена, а именно такая ситуация наиболее характерна для систем обслуживания, использование массива заданной длины является не слишком хорошим решением.

С одной стороны, всегда есть опасность того, что количество заявок в системе превысит заказанную компилятору длину массива, с другой -- задание длины массива «с запасом» приведет к необоснованному расходу памяти, которая поч- ти всегда является критическим ресурсом.

Есть еще одна причина, по которой в данной задаче следует предпочесть список. Речь идет о выписке выздоровевших больных. Палата на период лечения является контейнером для своих пациентов, а пациенты составляют ее основное содержимое, без них понятие палаты просто теряло бы смысл. Программно удаление пациента -- это удаление элемента (пациента) из содержащей его структуры данных (палаты). Поскольку этот удаляемый элемент может располагаться в любом месте структуры, использование списка предпочтительнее, так как операции вставки и удаления произвольного элемента выполняются для списков быстрее, чем для массивов.

Далее возникает новый вопрос: как объявить указатель на голову списка объек- тов класса Пациент -- как поле данных класса Палата или как обычную перемен- ную в функции main ()? Более предпочтительным представляется первый вариант. В eго пользу можно привести следующие доводы. При объявлении указателя на голову списка пациентов в функции main () логику обхода всех элементов списка нам придется реализовать тоже внутри основного моделирующего цикла в функ- ции main (), что сильно нарушит ее общность и простоту. Кроме того, объект Пала- та не будет иметь непосредственного доступа к своим пациентам, и нужно будет позаботиться о том, чтобы указатель на голову списка пациентов передавать в качестве параметра из метода в метод, начиная с метода run (). В принципе, ниче- го страшного в этом нет, но важно принять такое проектное решение, которое в наибольшей степени отвечает реальным взаимоотношениям объектов. Доступ палаты к пациентам должен быть совершенно естественным и не требовать ка- ких-то дополнительных программных усилий.

Подытожим наши рассуждения. В описание класса Палата войдут следующие переменные:

· текущее количество пациентов;

· указатель на голову списка объектов класса Пациент.

В описание класса Пациент войдет:

· текущая оценка состояния;

· текущее количество дней, проведенных в палате к настоящему моменту.

Заметим, что мы перечислили только те поля данных класса, которые меняются в процессе моделирования. Назовем такие поля изменяемыми. В описание класса войдут также неизменяемые поля, которые, будучи назначенными объекту при инициализации, не меняются на всем протяжении процесса моделирования. В данной задаче такими полями являются все перечисленные в условии число- вые константа. Распределять их по классам следует так, чтобы методы одного класса по возможности не обращались или обращались как можно меньше к не- изменяемым полям данных другого класса. Выбранный вариант распределения будет приведен далее в листинге программы.

3.2 События и методы

Для класса Палата переменная, хранящая текущее количество пациентов, может измениться в результате наступления одного из двух событий -- прибытия и выписки. Указатель на голову списка может измениться только в том случае, если соответствующий голове списка пациент будет выписан, но такое событие логично не выделять в отдельный метод, а обрабатывать внутри метода Выписка. Текущая оценка состояния класса Пациент меняется каждый день и должна ра- зыгрываться на каждом такте моделирующего цикла специальным методом, ко- торый можно назвать Изиенить оценку. Текущее количество дней просто увеличи- вается на единицу на каждом такте цикла, что в отдельном методе не нуждается. Теперь обсудим логику работы методов run (). Для класса Пациент метод run () всегда и вне зависимости от каких-либо условий должен произвести инкремент количества дней, проведенных в палате, и вызвать метод Изменить оценку. Поэтому в данном случае представляется разумным в виде исключения отказаться от метода run () для класса Пациент, а указанную логику реализовать внутри метода run () для класса Палата. Перечислим, что и в какой последовательности должен делать этот метод:

1. Произвести обход списка пациентов и каждому из них изменить оценку.

2. Произвести выписку тех пациентов, чья оценка свидетельствует о том, что они выздоровели (набрали 49 и более баллов).

3. Разыграть прибытие двух новых пациентов. Для каждого из них метод Прибытие произведет одно из следующих действий:

1) примет в палату на лечение при наличии свободных мест;

2) откажет в приеме, если свободных мест нет и оценка больного превышает 41 балл;

3) если свободных мест нет, но есть больной с оценкой, достигшей 47 баллов, выпишет этого больного и примет нового больного на лечение, если его оценка не превышает 41 балл;

4) откажет в приеме, если свободных мест нет и никто из больных не достиг оценки 47 баллов.

4. Увеличить всем больным в палате количество проведенных в ней дней на единицу.

5. Произвести действия по сбору требуемой статистики -- коэффициента загрузки палаты и среднего числа дней, проведенных больным в палате (после вызова метода Выписка).

4. Программная реализация алгоритма

При создания имитационной модели очереди с разнотипными заявками (работа порта) был выбран язык программирования C++ и написана программа на этом языке, позволяющая в полной мере отразить функционирование системы.

Листинг программы файл 7. h. Описание классов

#include< cstdio>

#include< cstdlib>

#include< ctime>

using namespace std;

#include «List. h» //подключаем файл, в котором описан шаблон

//для связных списков, см. главу 2

FILE *sojourn; // в этот файл будут записываться данные

//о длительности пребывания в палате выписанных

//пациентов

FILE *ro; // в этот файл будут записываться ежедневные данные

//о загрузке палаты

float ro_aver=0; // в этой переменной будет ежедневно пересчитываться

//средняя загрузка системы, гл. 5

float ill_aver=0; // в этой переменной будет пересчитываться среднее

//время пребывания пациентов в палате

long int total=0L; // счетчик общего числа больных, претендовавших

//на поступление в палату

long int reject1=0L; //счетчик числа больных, не принятых по причине

//отсутствия свободных мест и оценки, превышающей

//41 балл

long int reject2=0L; //счетчик числа больных, не принятых по причине

//отсутствия свободных мест и больных, достигших

//оценки 47 баллов

long int earlier=0L; //счетчик числа больных, выписанных досрочно

long int complete=0L; //счетчик числа больных, завершивших лечение

// и выписанных здоровыми

long int entered=0L; //счетчик числа больных, принятых на лечение

//в палату

class Pacient{

long int id; // уникальный идентификатор больного, позволяет

//отслеживать «историю болезни»

float current_mark; // текущая оценка состояния больного

int days_in_hosp; // количество дней, проведенных в палате на данный

//момент

const static int bottom=-2; //минимальное значение, на которое может

//измениться в течение дня текущая

//оценка состояния больного. Не стандартно

const static int top=12; //максимальное значение, на которое может

//измениться в течение дня текущая оценка

//состояния больного. Не стандартно

const static int init_bottom=30; // минимальное значение оценки

//состояния больного при поступлении

//на лечение. Нестандартно

const static int init_top=44; //максимальное значение оценки

//состояния больного при поступлении

//на лечение. Нестандартно

public:

friend class Palata; //класс Палата объявлен

//дружественным классу «Пациент».

//Альтернатива — написать public

//методы для чтения полей данных

//класса Пациент.

Pacient (int d): days_in_hosp (d) // метод-конструктор

{

//Розыгрыш первоначальной оценки. Предполагается, что число знаков

//после запятой в значении оценки не более единицы.

current_mark=init_bottom+(float)(rand ()%((int)((init_top-init_bottom)*10)+1))/10;

id=total; //идентификатор=порядковый номер поступившего

//больного

}

void change_mark (); // изменение текущей оценки состояния больного

void Print (); //вывод на печать информации о пациенте

};

void Pacient: :change_mark (){

current_mark+=(float)(bottom/10)+(float)(rand ()%((int)(((float)(top/10)-(float)(bottom/10))*10)+1))/10;

}

void Pacient: :Print (){

printf («Пациент %ld находится на лечении %d дней, текущая оценка %. 2fn», id, days_in_hosp, current_mark);

}

class Palata{

int current_number; //текущее число пациентов в палате

ListNode< Pacient> *ill; //указатель на голову списка пациентов

const static int volume=25; //количество мест в палате

const static int border1=41; //начальная оценка, при превышении

//значения которой и отсутствии

//свободных мест больной не принимается

//в палату на лечение. Не стандартно

const static int border2=47; //оценка, при достижении которой

//и отсутствии в палате свободных мест

//больной досрочно выписывается, чтобы

//освободить место новому больному.

//Не стандартно

const static int healthy=49; //оценка, при превышении которой

//больной считается вылечившимся.

//Не стандартно

public:

Palata ();

void run ();

void arrival (); //метод, обрабатывающий прибытие нового

//больного

void departure (ListNode< Pacient> *pac); //метод, моделирующий выписку

//больного из палаты, pac —

//указатель на элемент списка,

//в котором хранятся данные

//об этом больном

};

Palata: :Palata () //метод-конструктор

{

current_number=0; //первоначально в палате нет больных

ill=NULL;

}

void Palata: :run () {

int i;

float ro_val;

ListNode< Pacient> *ptr, *ptr1;

ptr=ill;

//Обход всех больных и пересчет их текущих оценок

for (i=0; i<current_number;i++){

ptr-> Data ()->change_mark ();

ptr=ptr-> Next ();

}

ptr=ill;

//Обход всех больных и выписка выздоровевших

while (ptr≠NULL){

if (ptr-> Data ()->current_mark>healthy) //если не объявить класс

//Палата другом класса

//Пациент, компилятор выдаст

//ошибку на этой строке

{

ptr1=ptr-> Next ();

departure (ptr);

ptr=ptr1;

}

else ptr=ptr-> Next ();

}

//прибытие двух новых больных

for (i=0; i< 2; i++){

arrival ();

}

ptr=ill;

//Обход всех больных и инкремент числа дней, проведенных в палате

for (i=0; i<current_number;i++){

ptr-> Data ()->days_in_hosp++;

ptr=ptr-> Next ();

}

//Вычисление текущей загрузки и запись в файл

ro_val=((float)(this-> current_number))/volume;

fprintf (ro,"%fn", ro_val);

//пересчет средней загрузки. Число дней вдвое меньше total

ro_aver=ro_aver*(1−2. 0/total)+2. 0*ro_val/total;

}

void Palata: :arrival (){

//int j;

Pacient *p=new Pacient (0); //создание нового объекта класса Пациент

ListNode< Pacient> *ptr;

int i;

total++;

if (current_number< volume) //в палате есть свободные места

{

ListNode< Pacient> *lp=new ListNode< Pacient>(p, NULL); //создание нового

//элемента списка

//пациентов

if (current_number==0) ill=lp; //если это первый пациент,

//он становится головой списка

else ListAdd< Pacient>(ill, lp); //иначе — добавление нового элемента

//в список

current_number++;

entered++;

return;

}

if (p-> current_mark>border1) //свободных мест в палате нет,

//начальная оценка превышает 41 балл

{

delete p; //удаление пациента

reject1++;

return;

}

//Свободных мест нет, начальная оценка не превышает 41 балл

ptr=ill;

for (i=0; i<current_number;i++) //ищем пациента, которого можно

//досрочно выписать

{

if (ptr-> Data ()->current_mark >= border2) // пациент найден

{

departure (ptr); //выписка

ListNode< Pacient> *lp=new ListNode< Pacient>(p, NULL); //создание нового

//элемента списка

ListAdd< Pacient>(ill, lp); //добавление нового элемента в список

current_number++;

entered++;

return;

}

}

delete p; //принять пациента в палату

//не удалось, удаляем объект

reject2++;

return;

}

void Palata: :departure (ListNode<Pacient> *pac){

int sojourn_val;

//Выписываемый больной выздоровел

if (pac-> Data ()->current_mark > healthy) complete++;

//Досрочная выписка

else if (pac-> Data ()->current_mark >= border2) earlier++;

sojourn_val=pac-> Data ()->days_in_hosp;

//Записываем в файл число дней, которое выписанный больной провел

//в палате

fprintf (sojourn, «%dn», sojourn_val);

//Пересчитываем среднее время пребывания в палате

ill_aver=ill_aver*(1−1. 0/(complete+earlier))+1. 0*sojourn_val/(complete+earlier);

current_number--;

//Удаляем элемент из списка

ill=ListDelete< Pacient>(ill, pac);

return;

}

Поясним логику выражения из метола Pacient: :change mark () проведением его пошаговой трассировки. Напомним, что нам необходимо сгенерировать число с одним знаком после запятой, находящееся в пределах отрезка [-0,2; 1,2]. Основ- ная трудность заключается в том, что функция rand () работает только с целыми числами.

1. Вычисляем значение 10*(top-bottom)=14.0.

2. Приводим результат к целому типу. Приведение не изменит фактического значения выражения, так как число с k знаками после запятой после умножения на 10* становится целым.

3. Прибавляем единицу, чтобы получить общее количество всех возможных смещений текущей оценки с учетом минимального и максимального — всего их 15.

4. Генерируем с помощью функции гапсК) и операции взятия остатка от деления случайное целое число, равномерно распределенное от 0 до 14.

5. Приводим его к типу float.

6. Результат делим на 10 и прибавлением к нижней границе отрезка получаем случайное значение смещения оценки, равномерно распределенное в заданном диапазоне.

Отметим также, что инициализация const static-членов класса внутри определе- ния класса (то есть совмещение инициализации с объявлением члена класса) по стандарту допускается только для полей данных целочисленного типа, к кото- рым относятся int, char, enum и др. Инициализация же поля данных const static float хоть и была «одобрена» используемым компилятором, стандартной не яв- ляется и должна производиться вне определения класса.

Например:

· const static float bottom: -- внутри определения класса Pacient;

· const float Pacient: :bottom = -0. 2: -- вне определения класса Pacient.

Листинг программы файл List. h

template < class Type> //это постоянная «заставка»

//к класам и функциям

//c парметризированным типом

class ListNode {

private:

ListNode< Type> *next; //указатель на следующий элемент списка

Type *data; //указатель на данные хранящиеся в элементе списка

public:

ListNode (Type *d, ListNode< Type> *n); //конструктор

~ListNode (); //деструктор

Type *Data (); //метод для чтения данных

ListNode< Type> *Next (); //метод для чтения указателя

//на следующий элемент

void PutNext (ListNode< Type> *n); //метод для записи указателя

//на следующий элемент

void Print (); //печать содержимого элемента списка

};

template < class Type>

ListNode< Type>:ListNode (Type *d, ListNode< Type> *n): next (n), data (d){

}

template < class Type>

ListNode< Type>:~ListNode (){

delete data;

}

template < class Type>

Type *ListNode< Type>:Data (){

return data;

}

template < class Type>

ListNode< Type> *ListNode< Type>:Next (){

return next;

}

template < class Type>

void ListNode< Type>:PutNext (ListNode<Type> *n){

next=n;

}

template < class Type>

void ListNode< Type>:Print (){

data-> Print (); //предпологается наличие метода Print () для класса

//имя которого будет подставленно в пользовательском коде

}

//Описание класса-шаблона завершено, далее идут функции-шаблона, работающие

//не с отдельным элементом, а со всеми списком

template < class Type>

void ListAdd (ListNode< Type> *head, ListNode< Type> *li) {

//добавление нового элемента li в хвост списка с головой head

ListNode< Type> *old, *v;

//ищем внешний хвост списка

for (v=head; v≠NULL; v=v-> Next ())

old=v;

old-> PutNext (li); //добавляем в след за найденым хвостом новый элемент списка

}

template < class Type>

ListNode< Type> *ListDelete (ListNode< Type> *head, ListNode< Type> *li) {

//удаление элемента li из списка с голоыой head

//функция возвращает указатель на голову нового списка

//int j;

ListNode< Type> *old, *o1;

if (li==head){

//удаляемый элемент может быть головой списка

//в этом случае голова у списка меняется

o1=head-> Next ();

delete li;

return o1;

}

//Удаляемый элемент не являеться головой списка. Голова остаеться прежняя

for (ListNode< Type>* v=head; v≠li; v=v-> Next ())

//поиск элемента предшедствующего удаляемому

old=v;

o1=li-> Next ();

old-> PutNext (o1);

//предшествующий элеиент теперь «видит» элемент стоящий в списке вслед

//за удаленным

delete li;

return head;

}

//печать всех элементов списка с головой head

template < class Type>

void ListPrint (ListNode< Type> *head){

for (ListNode< Type>* v=head; v≠NULL; v=v-> Next ())

v-> Print (); //подсчет количества элементов в списке с головой head

ПоказатьСвернуть
Заполнить форму текущей работой