2 этап – составление общей схемы моделирования.
При этом желательно пользоваться такими именами переменных, которые удовлетворяют правилам языка Pascal , а их аббревиатура соответствует смыслу этих переменных. В частности, рекомендуем следующие имена: KOL(1) – количество заявок, поступивших в систему от I-го источника; KOBR(I), KOTK(I) – количество обработанных и получивших отказ заявок от I-го источника соответственно; TPOST(J) – момент поступления заявки от J-го источника; NMIN – номер источника, от которого пришла заявка раньше; THO – момент начала обслуживания заявки прибором; TAYOB – длительность обслуживания; TOSV – момент освобождения прибора; INDBUF – индикатор буфера (количество заявок в буфере); BUFT(K) – буфер моментов поступления заявок (массив из K элементов); BUFN(K) – буфер номеров источников, которым принадлежат соответствующие заявки, хранящиеся в BUFT; LAM(I) – массив интенсивностей входных потоков или потоков обслуживания, если потоки однотипны и их удобно индексировать; LAMOB – интенсивность потока обслуживания; TAY1 – (или с другими цифрами в конце имени) – параметры других потоков; DLAM – приращение интенсивностей; DTAY – приращение параметра потока; KMIN – длина реализации для достижения заданной точности; BOTK(I) – вероятность отказа от обслуживания заявки I-го источника; MTOG(I) – математическое ожидание заявки от I-го источника в буфере; TOG(I) – общее время ожидания в буфере заявок от I-го источника.
Размеры соответствующих массивов определяются условиями задачи.
При выполнении курсовой работы рекомендуем один из наиболее простых подходов к моделированию подобных систем, а именно обработку очередного события в активных элементах системы в зависимости от состояния или статуса всех остальных элементов.
В соответствии с этой методикой за активные элементы описанной выше системы примем прибор и источники заявок. Общая схема моделирования будет иметь следующий вид (рис.4). Блок определения очередного события (БООС) выбирает наименьшее из трех моментов времени: TPOST(1), TPOST(2), TOSV.
Первый случай соответствует событию «пришла заявка от первого источника», второй случай – событию «пришла заявка от второго источника», а третий – событию «прибор закончил работу (обслужил заявку)». Этим трем случаям соответствуют выходы из блока БООС, помеченные цифрами 1, 2 и 3.
На втором этапе разработки алгоритма надо словами описать назначение каждого из блоков укрупненной схемы алгоритма, представленной на рис.4, т.е. необходимо сформулировать «что надо сделать», пока не задумываясь о том , «как это сделать».
Блоки анализа статуса БАС1, БАС2 и БАС3 в общем случае могут выполнять различные действия по анализу, т.к. эти действия зависят от того, какое событие произошло, и какие изменения в системе надо будет смоделировать как следствие от происшедшего события. Не задумываясь пока о том, насколько схожими будут действия по анализу состояния системы, надо описать (специфицировать) функции БАС1, БАС2 и БАС3. Блок БАС1 должен обеспечить выполнение действий, являющихся следствием события «пришла заявка от первого источника», а именно:
1. Записать заявку в буфер, если в нем есть место;
2. Отказать в заявке от первого источника, если в буфере нет места;
3. Сформировать следующую заявку первого источника.
При этом действия 1 и 2 взаимно исключают друг друга, а действие 3 должно иметь место всегда. Блок БАС2 должен обеспечить действия, являющиеся следствием события «Пришла заявка от второго источника», а именно:
1. Записать заявку от второго источника в буфер, если в нём есть место;
2. Отказать в обслуживании заявке от второго источника, если в буфере нет места;
3. Сформировать следующую заявку второго источника.
Первые два действия также исключают друг друга, а третье должно иметь место всегда.
Учитывая, что запись в буфер по условию задачи не зависит от номера источника (бесприоритетна), можно действия БАС1 и БАС2 при дальнейшей детализации алгоритма совместить, а также совместить часть действий в блоках модификации состояния БМС.
Итак, блоки БАС1 и БАС2 анализируют индикатор состояния буфера INDBUF, обеспечивая дальнейшее разветвление на два направления, т. к. для дальнейшего важно знать лишь одно: INDBUF < 4 или INDBUF = 4.
Блок БАС3 должен обеспечить моделирование следующих событий:
1. Если в буфере есть заявки, взять одну из них на обслуживание в соответствии с дисциплиной выборки, определённой заданием;
2. Если в буфере заявок нет (а произошло событие «Прибор закончил работу»), то прибор необходимо освободить, т. е. вернуться к ситуации, имевшейся в начале моделирования, когда были прогенерированы две заявки, прибор был свободен , и решалась судьба заявки, пришедшей раньше. Другими словами, во втором случае никаких изменений, кроме освобождения прибора, моделировать не надо, т. е. можно снова вернуться к блоку БООС, выполняющему функции КАЛЕНДАРЯ событий.
Если у вас есть фирма, тогда вам просто необходим сайт, http://rusiter.com вы можете тут.
Таким образом, в результате словесного описания функций блоков БАС стало ясным, что необходимо анализировать лишь состояние буфера (точнее, значение переменной INDBUF). Состояние же прибора специально анализировать в БАС не надо, т. к. «Прибор закончил работу», если TOSV < TPOST (NMIN).
Опубликовал Kest
July 16 2014 21:17:27 ·
0 Комментариев ·
3549 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.
Главная
Каталог файлов
