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

Отладка моделей в процессе их выполнения

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

Итоговая таблица состоит из 12 столбцов, каждый из которых несет определенную смысловую нагрузку. Если в выходном документе меньше 12 столбцов, то их взаимное расположение не изменяется.

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

• выйти в режим трассировки после конкретного события;

• перейти в трассировку, если какой-то транзакт входит в определенный узел или выходит из него;

• отслеживать путь конкретного транзакта по сложному графу модели;

• выйти в режим трассировки по показанию модельного таймера.

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

Особенности замкнутых моделей корпоративных информационных систем

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

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

• пользователи (или группы пользователей, в зависимости от сложности моделируемой системы) представляются одно- или многоканальными узлами типа serv (серверы);

• число каналов сервера соответствует числу пользователей, время обработки транзакта сервером соответствует времени подготовки пользователями запроса;

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

• для зарядки транзактами серверов пользователей, принадлежащих к одному классу, используется единственный генератор, порождающий всего один транзакт. Далее транзакты размножаются с помощью узлов типа creat.

Ниже представлены варианты зарядки модели транзактами.

1. Зарядка одного многоканального сервера

По графу модели начинает циркулировать столько запросов, сколько имеется пользователей. Адрес же возврата запроса можно определить по значению параметра t->ft «номер семейства». В случае с одним сервером пользователей эта проблема не столь актуальна, тогда как в двух описанных далее случаях этот способ очень удобен.

2. Зарядка нескольких одноканальных серверов.

Отличие этой схемы от варианта 1 состоит в введении дополнительного узла queue.

3. Зарядка нескольких многоканальных серверов. Этот вариант отличается от варианта 2 введением второго узла creat.

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

1. добавить в модель дополнительный узел key и с его помощью проводить замеры времени реакции;

2. получить с помощью модели средние времена пребывания транзактов во всех узлах имитационной модели КИС и использовать эти данные для расчета времени реакции;

3. использовать только среднее время подготовки конкретным пользователем запроса (или задания) для КИС, полученное с помощью модели, и загрузку узла serv, имитирующего этого пользователя.

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

Состав проекта и применение оболочки Developer Studio

Обычно имитационная модель создается в среде Developer Studio с применением средств Visual C++. Проект относительно разработки программ - это приложение Windows. Предположим, что среда Developer Studio расположена на жестком диске С в папке Msdev (путь c:\Msdev), а файл с текстом модели в терминах Pilgrim находится в папке с именем ModelDir на жестком диске D (путь d:\ModelDir). Текст модели - это файл, созданный текстовым редактором Developer Studio или Notepad, имеющий срр-окончание (суффикс), например ModelText.cpp. Для определенности назовем наш проект ModelPro.

Рассмотрим типовые технологические последовательности действий, необходимые при создании, модернизации и выполнении моделей. Во всех режимах используются три клавиши меню Developer Studio: File - файл, Insert - вставить и Build - построить.

Создание моделей. Создание новой модели обычно проходит с использованием следующего пути по меню и подменю: File → New → Project Workspace → режим Application → выбор папки ModelDir (можно через режим Browse) → указание имени проекта ModelPro. В результате будет создан файл управления проектом ModelPro.mdf.

Дальнейшие действия различаются в зависимости от типа проекта:

• типовой проект модели;

• проект модели с диалоговым окном для управления параметрами при ее запуске или во время выполнения;

• проект модели с функциональным окном для конечного пользователя (вывод информации в понятном для потребителя виде).

Типовой проект модели. Создание типового проекта не требует от разработчика знаний языка C++. Проект состоит из четырех файлов:

• текст модели ModelText.cpp. Находится в папке d:\ModelDir;

• общая библиотека Comctl32.1ib, содержащая средства Windows и Pilgrim. Ее состав слабо изменяется при разработке новых версий моделирующей системы Pilgrim. Она находится в папке c:\Msdev\Lib;

• библиотека Pilgrim.lib. Существенно изменяется в процессе развития системы Pilgrim. Ее можно найти в папке c:\Msdev\Lib;

• файл ресурсов Pilgrim.res. Также изменяется в процессе развития системы Pilgrim. Его можно найти в папке c:\Msdev\Projects.

Все вышеперечисленные файлы подключаются к проекту с использованием клавиши Insert общего меню Developer Studio. Обычно в меню и подменю выполняются действия: Insert → Files into Project → выбор суффикса (срр, lib, res) → определение пути к файлу → подключение.

Далее выполняются компиляция и сборка модели: выбирается клавиша Build общего меню Developer Studio и режим Rebuild All. В результате создается выполняемая модель: файл ModelPro.exe.

Запуск готовой модели из общего меню можно выполнить так: Build → Execute ModelPro.exe.

Проект модели с диалоговым окном для управления параметрами. Создание такого проекта требует от разработчика некоторых знаний Visual C++.

Сначала необходимо скопировать из папки c:\Msdev\Projects в папку d:\ModelDir следующие пять файлов: Parametr.cpp, Palette.bmp, Pilgrim.ico, UserHid.h, UserRes.rc. Проект имеет следующий состав:

• текст модели ModelText.cpp. Находится в папке d:\ModelDir;

• типовая программа Parametr.cpp. Программа написана на языке C++; в зависимости от количества регулируемых параметров ее необходимо настраивать на модель. Она также находится в папке d:\ModelDir;

• общая библиотека Comctl32.1ib, содержащая средства Windows и Pilgrim. Находится в папке c:\Msdev\Lib;

• библиотека Pilgrim.lib. Она существенно изменяется в процессе развития системы Pilgrim. Находится в папке c:\Msdev\Lib;

• файл ресурсов UserRes.rc. Находится в папке d:\ModelDir. Написан на языке создания Windows-ресурсов. В зависимости от количества регулируемых параметров этот файл необходимо настраивать на модель.

Прежде чем компилировать и собирать модель, рассмотрим отдельно файл ресурсов UserRes.rc и типовую программу Parametr.cpp.

Файл ресурсов имеет две части: неизменяемую (стандартную) и изменяемую. Макет файла - это UserRes.rc. Текст изменяемой части на языке описания ресурсов Vsual C++ приведен ниже (см. приложение 1).

Этот файл обеспечивает вывод диалогового окна для управления 20 параметрами модели (рис. 7.5). Если такое количество велико, то можно изменить (сократить) текст файла UserRes.rc для сокращения размеров этого окна и уменьшения количества наблюдаемых или управляемых параметров модели. Кроме того, можно задать совсем другое расположение внутренних окошек для наблюдения за параметрами.

В данном примере количество окошек избыточно, задействовано только 3 из 20 для отображения и управления тремя параметрами модели: 1) float win0l «Время моделирования»; 2) float win02 «Прибытие пассажиров»; 3) float win03 «Интервал подхода такси». Зарезервировано одно окошко (с номером 11) для отображения параметра float winl1, который в модели не используется.

Начальные значения переменных win0l, win02, win03, winll, а также заголовки и надписи задаются в головной части текста модели:

После возможной корректировки файлов UserRes.rc и Parametr.cpp выполняется компиляция и сборка модели, для чего используется клавиша Build общего меню Developer Studio и режим Rebuild All. В результате создается выполняемая модель ModelPro.exe. Запуск модели: Build → Execute ModelPro.exe.

Проект модели с функциональным окном для конечного пользователя. Часто бывает необходимо показать конечному пользователю информацию в понятном ему проблемно-ориентированном виде. Это могут быть изменяющиеся таблички, графики, перемещающиеся по экрану изображения (например, автомобили). Такой пользователь не будет изучать моделирующую систему. Поэтому для него средствами Visual C++ создается специальная функциональная программа funcwindow, которая помещается в динамически вызываемую библиотеку Windows (dll-библиотеку). Обращение к такой библиотеке производится после каждого события в модели. После первого события она загружается в оперативную память. Типовые операторы Visual C++ , используемые при создании такого окна, приведены в приложении 2.

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

• на всякий случай принудительно сохранить последний модифицированный текст модели (если модификации были), выполнив действия File → Close через главное меню Developer Studio или нажав значок «дискета» на панели инструментов;

• затем либо просто выйти из Developer Studio (если нет других проектов), либо в главном меню выполнить действия: File → Close Workspace (если нужно перейти к другому проекту).

Модернизация моделей возможна всегда. Чтобы выполнить модернизацию, через меню Developer Studio открывается существующий проект: File → Open Workspace.

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

Выполнение моделей. По умолчанию создается ехе-файл в папке Debug, вложенной в папку с проектом. Это и есть компьютерная модель. В ехе-файле есть все необходимое для отладки модели. Окончательный вариант отлаженной модели обычно берется из папки Release: он работает быстрее и меньше по объему.

В процессе отладки модель запускается из папки Debug одним из двух способов:

• нажатием комбинации клавиш Ctrl+F5;

• через главное меню Build → Execute ModelPro.exe.

Файл с моделью можно переписать в любую другую папку и на любой другой компьютер. Он всегда будет работать.