Общая оценка GPSS World
 
GPSS/W является весьма ценным инструментом имитационного моделирования, свободным от ограничений аналитических и численных методов, достаточно «прозрачным», допускающим нестандартную обработку данных и снимающим с программиста множество нетривиальных проблем программирования и отладки моделей. Тем не менее, приходится отметить наличие у нее ряда серьезных недостатков:

1. Громоздкость системы и явная перегруженность встроенными возможностями (многообразие примитивов); непомерное разнообразие графических обозначений блоков, не поддерживаемое даже новейшими версиями «чертежной» системы Visio.

2. Медленная работа интерпретатора.

3. Отсутствие концептуального единства. Достаточно указать, например, различие в обращении к элементам матрицы при простой ссылке и изменении значения, круглые индексные скобки в основном тексте и квадратные - в PLUS-выражениях; обязательность приставки MX$ при ссылке на глобальную матрицу в тексте модели и столь же обязательное ее отсутствие внутри процедур; контекстно зависимый вид ссылок на параметры активного транзакта; потерявшее смысл в GPSS/W различение переменных VARIABLE и FVARIABLE; выражение коэффициента использования устройства в тысячных долях.

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

5. Неудачные обозначения операторов отношения L, G, E (было бы лучше согласовать с фортрановскими LT, GE, EQ); арифметическое SQR используется для квадратного корня (в Паскале так обозначается квадрат); в связи с «числовым» представлением логических значений и объединением понятий числового равенства и логической эквивалентности нарушено общепринятое старшинство операций; состояние логических ключей описывается как SET и RESET (буквальный перевод «установлен» и «установлен заново») вместо ON, OFF; операнд RE (традиционный смысл этой приставки - повторение действия) означает удаление.

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

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

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

9. Использование кириллических символов даже в комментариях исключают правильную работу Имитации. 

10. Невозможно непосредственно определить вектор. Нижняя граница индексов матрицы по любому измерению равна 1, что может нарушить естественность индексации (например, при расчете вероятностей состояний системы). Крайне неудобен просмотр матриц через динамическое окно: одновременно можно видеть только два столбца. Ненулевая инициализация матрицы требует отдельного оператора INITIAL на каждый элемент. 

11. Отсутствует возможность регулировать темп автоматического моделирования; он оказывается слишком быстрым, чтобы разглядеть нужные эффекты, а пошаговое продвижение транзактов - чересчур медленным. 

12. Иконки свернутых динамических окон неразличимы, и при их восстановлении трудно выбрать желаемое. 

13. Нельзя менять тип шкал графиков (только линейные) и их разметку, цвет и структуру линий, что может сделать последние неотличимыми друг от друга и/или от фона при черно-белом выводе.

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

15. При работе с ANOVA нельзя менять расчетный уровень значимости.

16. Оставляет желать лучшего электронная документация к системе. При вызове Help'а по ключевому слову пользователю представляется «слепое» множество альтернатив, так что приходится выполнять их перебор. Часто встречаются пережитки предыдущих версий (GPSS/PC). Отсутствует упоминание о наличии в системе операции отрицания 'NOT'. Заявление о числовом значении "his value has a magnitude limited to 306 decimal digits" можно понять как длину мантиссы, хотя на самом деле речь идет о модуле десятичного порядка. Ничего (кроме факта существования) не сказано о библиотеке . В разделе определения табличных функций понятие обратной функции заменено кумулянтой. В заголовке определения команды MATRIX неверно указано число операндов, не выделен строкой и буквой неиспользуемый первый операнд. Этот перечень можно было бы продолжить.

17. «Универсальность» интерпретатора GPSS оказывается ограниченной. Так, обслуживание с динамическим приоритетом (линейный рост приоритетов по времени ожидания с угловыми коэффициентами, зависящими от типа заявки), в GPSS даже с помощью мощного аппарата цепей пользователя обеспечить не удается. Дело в том, что цепь может быть переупорядочена произвольно только в момент входа в нее новой заявки, тогда как нам для реализации динамического приоритета необходимо переупорядочение в момент выборки. На такой момент максимум возможного - это инверсия, т.е. реализация дисциплины LIFO (Last In - First Out). Предложенная в книге Шрайбера ([9], с. 391) схема «динамического приоритета» на самом деле реализует другую дисциплину выбора из очереди: по возрастанию времени обработки.


Трудности возникают также при моделировании «кругового» обслуживания. Для организации обслуживания всех заявок, накопившихся к началу обслуживания данной очереди, необходима переменная, запоминающая начало обслуживания текущей очереди. Ее значение наряду со значением указателя Pointer учитывается по схеме логического умножения при допуске к серверу очередной заявки. Не пропущенные заявки приходится записывать в цепь пользователя. При завершении обслуживания текущей очереди для каждого источника анализируется суммарное число заявок в очереди и в цепи. Однако после выбора нового положения стрелки блок UNLINK требует указания имени блока, в который адресуются освобождаемые заявки. Это имя в нашей модели можно получить с помощью функции Catenate присоединением к стандартному префиксу Inc номера выбранного источника. Но по синтаксису GPSS имя блока не может быть строкой, и моделирование завершается аварийно. Безуспешными оказались и попытки использовать числовые обозначения блоков c помощью команды EQU (было получено сообщение "You can assign your own value to entity label except for block labels").

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

Кстати заметим, что Дж. Шрайбер скептически оценивает полезность цепей пользователя и в особенности их индикаторов связи ([9], с. 385). В его книге объемом в 70 авторских листов приведены лишь два не очень убедительных примера работы с цепями пользователя, а в [7] – ни одного.

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

С другой стороны, при определении тенденций оптимизации часто помогает рассмотрение компонент целевой функции. Например, в задачах управления запасами [4] минимизируется сумма затрат на хранение избыточного (среднего) запаса, организацию поставок и «штрафы» за неполное или несвоевременное обеспечение спроса. Большой удельный вес одной из упомянутых составляющих указывает на необходимость соответственно уменьшения уровня заказа, предельного уровня запаса или объема заказываемой партии; увеличения максимального запаса или объема заказываемой партии, увеличения порога заказа. Оптимизирующие эксперименты GPSS/W такой возможности не предусматривают. Ясно, что никакая «универсальная» система подобную специфику учесть не может.

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

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

 
назад

вперед