ListLine

Tlist

Список дуг.

AttributeNames

TstringList

Имена атрибутов фишек

AttributeTypes

TstringList

Типы атрибутов фишек

NetVarNames

TstringList

Имена сетевых переменных

NetVarVals

TstringList

Значения сетевых переменных

NetVarTypes

TstringList

Типы сетевых переменных

При визуальном отображении разработанной подсистемой используются свойства ListPos и ListNet.

1.5.3 Компоненты Е-сети

Все компоненты Е-сети в СВПИМ порождены от базового класса TNObject и перегружают все его виртуальные функции. Кроме того, каждый из компонентов имеет собственные данные и методы, специфичные для него.

Переходы представлены в редакторе классом TNetObj. Кроме свойств, определенных в базовом классе, объект имеет набор собственных свойств, описывающих тип перехода, ширину графического изображения, высоту графического изображения, выражение в операторе TIME, выражение в операторе CONTROL, выражение в операторе TRANSFER и т.д.

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

Дуги представлены классом TlineObj Кроме свойств, определенных в базовом классе, объект имеет следующий набор собственных свойств: тип дуги, направление дуги, указатель на переход, к которому присоединена дуга, указатель на позицию, к которой присоединена дуга и т.д.

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

Класс TNetObj:

TNetObj = class (TNObject)

public

TypeNet:TAllTypeNet;

ResizeRgn:HRGN;

Width:integer;

Height:integer;

HeightVertLine:integer;

IsPassed:boolean; (*добавленное свойство*)

Свойство IsPassed описывает состояние перехода (срабатывающий или нет)

Класс TPosObj:

TPosObj = class (TNObject)

public

TypePos:TAllTypePos;

Width:integer;

Height:integer;

Orientation: Boolean;

Length: Longint;

Pos1, Pos2:TPoint;

InOutPoint: array [1..2] of TPoint;

SatatusInOutPoint:array [1..2] of TWayLine;

OrientationRgn:HRGN;

NumPoints:integer; (*добавленное свойство*)

Свойство NumPoints описывает количество фишек в позиции.

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

Структура подсистемы имеет следующий вид:

1.6.1 Обработка файла созданного МИКРОСИМ

Файл с данными о сработавших переходах создается в результате работы МИКРОСИМ. Структура файла описана в п. 2.3.3. Имя файла задается в виде <имя модели>.log, располагается он в директории МИКРОСИМ. При некорректном задании параметров моделирования размер файла может достигать нескольких мегабайт. Очевидно, что активная работе с таким файлом будет затруднена из-за ограниченной пропускной способности дисковой системы.

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

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

OneLine= Record

Segment: string (*имя сегмента*);

Perehod: string (*имя перехода*);

Ttime: real (*текущее модельное время*);

Ddelay: real (*задержка*);

FromPos: String (*имя входной позиции*);

FromCount: integer (*кол-во фишек*);

ToPos: string (*имя выходной позиции*);

ToCount:integer (*кол-во фишек*);

end;

В процессе обработки файла организуется список из таких записей, в порядке следования сработавших переходов.

1.6.2 Начальная маркировка модели

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

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

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

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

1.6.3 Визуальное отображение

Таким образом перебираются все сработавшие переходы и поведение модели можно пронаблюдать на экране.

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

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

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

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

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

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

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

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

Второй этап - этап начальной маркировки модели.

Третий этап - этап визуального отображения.

2. Технология интеграции Windows и DOS-приложений

До настоящего времени наиболее широко распространенной операционной системой являлась система MS-DOS. Развитие и совершенствование компьютерных технологий привело к появлению новых, более совершенных операционных систем, основное отличие и преимущество которых заключается в их многозадачности. Одной из таких ОС стала операционная среда Microsoft Windows 3.x, и впоследствии, Windows'95, Windows'98 и Windows'NT. Данные операционные системы получили широкое распространение в нашей стране и за рубежом, благодаря удобному графическому интерфейсу и мультизадачности.

Если мы вспомним историю развития средств разработки программ, то увидим следующее. Сначала была интеграция - в единой программной среде программисты получали редактор, компилятор и компоновщик. Примерами таких сред были компиляторы фирмы Borland - Turbo Pascal, Turbo C, Turbo C++ и многие продукты других фирм. Выпуск Windows вызвал появление широкого интереса к разработке программ для этой среды и, как следствие, - необходимость в средствах разработки Windows - программ. Так появились первые компиляторы для Windows, принципиально не отличавшиеся по идеологии от своих DOS_собратьев. Практически сразу же за компиляторами появились различные генераторы приложений (кодогенераторы), которые выполняли две роли. Они выступали как средство для построения прототипов программ - позволяли без программирования построить интерфейс будущей программы, и как средство для автоматической генерации кода. Благодаря этому программист постепенно освобождался от непосредственного написания кода и получал некоторое средство для визуального, наглядного создания приложений.

Среда программирования Delphi является попыткой объединения всего лучшего, из того, что было создано на тему визуального программирования. Delphi - это не просто новая версия компилятора языка Turbo Pascal, а принципиально новый программный продукт, позволяющий создавать широкий спектр приложений для среды Windows.

Одним из таких приложений стала разработанная в МГИЭТ система визуального программирования имитационных моделей - СВПИМ, предназначенная для создания моделей, решаемых системой имитационного моделирования МИКРОСИМ, реализованной на языке Турбо Паскаль 7.0 и являющейся DOS_приложением. Виду возникновения необходимости совместного использования СВПИМ и МИКРОСИМ возникла потребность их интеграции в рамках единой программной оболочки, для дальнейшего использования в среде Windows. Этой проблеме просвещенна данная глава дипломного проекта.

2.1 Интеграция Dos - и Windows-приложений

2.1.1 Объединение МИКРОСИМ и СВПИМ

Операционная система Window's позволяет запускать на выполнение любое Dos - приложение. В Delphi также предусмотрена возможность запуска любого *.EXE - файла. Поэтому простейшим объединением двух Windows- и Dos_приложений является запуск на выполнение одной из программ на определенном этапе работы другой. В рамках данного дипломного проекта был реализован именно такой способ интеграции, являющимся не самым красивым и, может быть не самым правильным, но в данном случае единственно возможным, по независящим от автора причинам. Тем не менее были проведены исследования, связанные с возможностью перевода Dos - приложений, написанных на языке Pascal, на язык Delphi.

2.1.2 Создание программ на Delphi

Для начала вкратце рассмотрим, что представляет из себя программа на Delphi. Основное назначение Delphi - служить средством для быстрого создания широкого класса Windows - приложений. [5] Среда Delphi включает в себя полный набор визуальных средств для быстрой разработки приложений, поддерживающих создание пользовательских интерфейсов. В Delphi используется язык Object Pascal, полностью поддерживающий предыдущие версии языка Pascal. Таким образом, работа в Delphi заключается в работе с объектами.

Объект или, в терминологии Delphi - компонет, обладает набором свойств, определяющим его представление и поведение. Свойства влияют на то, как объект выглядит и на его невидимые черты (поведение), они непосредственно связанны с объектом - являются его атрибутами, описывающими его детальное строение.

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

Процесс создания приложений в среде Delphi сводится к следующим этапам:

Построение интерфейсной части приложения.

Написание кода для обработчиков событий.

Написание дополнительного кода.

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

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

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

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

Создаваемое приложение состоит из набора файлов - проекта. Ими могут быть файлы, создаваемые в среде Delphi, - файлы с исходным текстом модулей (расширение.PAS), формы являющиеся графическим представлением приложения (расширение.DFM), и сами файлы проектов (расширение.DPR).

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

2.1.3 Перевод приложения на язык Delphi

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

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

Наиболее правильным вариантом был бы перевод МИКРОСИМ на объектно-ориентированный язык, но на подобные преобразования, в виду очень большого объема программы, ушло бы значительное время. Поэтому остановимся на рассмотрении несколько иного способа интеграции.

Этапы перевода любого приложения, написанного на языке Pascal на Delphi аналогичны этапам разработки предложений на этом языке:

Создание нового интерфейса.

Написание кода для обработчиков событий.

2.1.3.1 Создание нового интерфейса

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

В таблице 3.1 приведено описание основных стандартных визуальных компонентов, которые могут быть использованы при создании интерфейса программы.

Таблица 3.1

Стандартные визуальные компоненты	Класс, которым представлен компонент
Главное меню	TmainMenu
Локальное меню	TpopupMenu
Статический текст	Tlabel
Строка редактирования	Tedit
Редактор	Tmemo
Стандартная кнопка	Tbutton
Кнопка с независимой фиксацией	TchekBox
Кнопка с зависимой фиксацией	TradioButton
Список	TlistBox
Комбинированный список	TcomboBox

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

Меню любого Dos - приложения, может быть легко и быстро построено в среде Delphi, и может быть аналогичным меню, либо иметь любой иной вид.

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

Например, при нажатии кнопки, представленной классом TButton, может вызываться стандартная Pascal_процедура:

procedure TForm1. Button1Click (Sender: TObject);

begin

Proc1 (i);

end;

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

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

2.2 Прохождение задания в интегрированной в СВПИМ системе МИКРОСИМ

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

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

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

Рис 3.2

Запуск МИКРОСИМ осуществляется непосредственно из редактора (пункт меню «файл / запустить Microsim», (рис 3.2) что увеличивает удобство его использования, и исключает необходимость выхода из редактора с целью осуществления процесса моделирования в среде МИКРОСИМ. Однако совместное использование СВПИМ и МИКРОСИМ не является обязательным. Работа с МИКРОСИМ начинается как обычно, с работы в креативной подсистеме.

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

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

Работа с креативной подсистемой начинается с работы в ее текстовом редакторе, который предоставляет исследователю возможность просмотра и редактирования текстового описания модели на ЯОМ, а также редактирование файлов на ЯЗП (пункт меню «Model / Parameters…», рис. 3.3).

Рис. 3.3

Описание каждого сегмента на ЯОМ, созданное при помощи СВПИМ подвергается следующим последовательным преобразованиям:

компиляция сегмента с языка ЯОМ на язык турбо Паскаль (получаются два компонента сегмента - сетевой и процедурный, первый из них запоминается в файле с расширением NET, а второй - в файле с расширением PAS);

компиляция процедурного компонента сегмента с языка Туpбо Паскаль с использованием компилятора командной строки (получается модуль в формате TPU, который запоминается в файле с расширением TPU).

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

Как уже отмечалось, стандартное расширение двух названных файлов - NET и PAS. Например, после второго преобразования сегмента из файла SEG.JOM будут получены два файла SEG.NET и SEG.PAS.

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

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

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

Назначение исполнительной подсистемы - проведение экспериментов при выполнении модели. Функции исполнительной подсистемы реализует отдельный загрузочный модуль. Его работа происходит в диалоговом режиме взаимодействия с пользователем.

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

Первое из требований заключается в указании предложения TRACE ALL при задании параметров модели. Сам по себе язык задания параметров предназначен для контроля состояния сформированных Е-сетевых моделей на стадии их выполнения (интерпретации). ЯЗП дает возможность задавать начальную маркировку позиций в сегментах модели, устанавливать или изменять значения сетевых переменных и сетевых массивов, назначать и отменять сбор статистики по избранным позициям и переходам модели, задавать и сбрасывать признак трассировки срабатывания переходов при выполнении модели, специфицировать условия остановки выполнения модели (не считая истечения заданного модельного времени и возникновения особых ситуаций). Все изменения, вносимые в Е-сетевую модель с помощью предложений ЯЗП, не требуют повторной компиляции и сборки модели, что упрощает проведение экспериментов над однажды скомпилированной и скомпонованной моделью. Как было отмечено выше, ввод предложений ЯЗП осуществляется либо непосредственно в исполнительной подсистеме, либо, с помощью текстового редактора в файл с расширением.JZP, который обрабатывается компилятором ЯЗП непосредственно перед запуском модели на исполнение.

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

В качестве третьего требования, хотелось бы указать необходимость грамотного указания единиц времени моделирования. Проведенные исследования и эксперименты показали, что даже для небольших моделей несовпадение в указании модельного времени при описании модели на ЯОМ и единицы времени, указанном при запуске модели может привести к увеличению необходимого для создания требуемого файла объема дискового пространства. Например, для модели многотерминальной вычислительной системы состоящей из процессора и трех терминалов, задания с которых поступают через интервалы времени, равные соответственно 10, 20 и 30 секунд, указание при запуске модельного времени в микросекундах приводит к тому что при времени моделирования равном одной секунде, файл имеет объем порядка 18_ти Мбайт. При правильном указании единиц времени моделирования файл с результатами работы той же модели за время равное 1000 секунд, имеет объем порядка 17_Кбайт.

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

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

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

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

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

Следует отметить, что имя создаваемого для подсистемы визуализации файла совпадает с именем модели.

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

Рис 3.4

Начало визуального отображения происходит с запроса имени файла (рис. 3.5). Файл должен находится в каталоге MICROSIM / BIN, в противном случае система диагностирует ошибку, либо в каталоге MNEDITOR, при условии, что MICROSIM отсутствует на дисках.

Рис 3.5

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

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

Рис 3.6

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

Просмотр результатов моделирования

Рис 3.7

Как было отмечено выше, результаты моделирования в виде таблиц, содержащих информацию о результатах интерпретации модели, могут быть просмотрены в самой подсистеме, либо сохранены в файл, с расширением по умолчанию *.dat. Поскольку работа в редакторе подразумевает осуществление всех этапов исследования модели в его рамках, была учтена и необходимость просмотра файла. Для этого нужно выбрать пункт меню «Файл / Результат» (рис 3.7). И открыть требуемый для просмотра файл.

Рис. 3.8

1

3. Оценка конкурентоспособности изделий

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

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

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

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

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

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

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

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

3.1 Анализ конкурентоспособности изделий

Анализ и оценка спроса на конкретный товар являются важной стратегической задачей и жестко связаны с жизненным циклом товара.

Жизненный цикл товара - важнейшая концепция, которая рассматривает динамику конкурентоспособного пребывания товара на рынке. Этапы жизненного цикла охватывают периоды времени от ввода товара на рынок, до его ухода. Каждый из них обладает особенностями и имеет собственные названия, принятые в маркетинге: зарождение, рост, зрелость, насыщение, спад.

Этап зарождения характеризуется медленным увеличением объема продаж. Для принципиально новых товаров этот этап может быть достаточно продолжительным.

Этап роста связан с интенсивным нарастанием продаж, отражающим увеличение популярности товара по мере осведомленности покупателей.

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

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

Спад - этап постоянного снижения спроса и объема продаж, потеря интереса к товару.

Уровень сбыта на различных этапах жизненного цикла товара зависит от конкурентоспособности товара в этот период.

Конкурентоспособность товара - совокупность свойств товара, делающих его более предпочтительным по сравнению с товарами конкурентов на данном рынке.

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

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

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

, (1)

Определить, соответствует ли определенный товар этому условию, можно лишь в процессе его сравнения с другими представленными на рынке товарами.

Таким образом, оценка конкурентоспособности товара, планируемого к продаже, включает следующие этапы:

анализ рынка и выбор наиболее конкурентоспособного товара-образца в качестве базы для сравнения и определения уровня конкурентоспособности нашего товара;

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

расчет интегрального показателя конкурентоспособности нашего товара.

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

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

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

«Мягкие» параметры характеризуют эстетические свойства товара (дизайн, цвет, упаковка и т.п.).

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

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

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

Величины экономических параметров определяется ценой изделия Ц1, расходами на его транспортировку Ц2, установку Ц3, обучение персонала Ц4, эксплуатацию Ц5, ремонт Ц6, техническое обслуживание Ц7, налоги Ц8, страховые взносы Ц9 и т.д. В совокупности эти расходы составляют цену потребления Ц - объем средств, нужных потребителю в течение всего срока службы товара:

Ц = Ц₁ + Ц₂ + Ц₃ +Ц₄ + Ц₅ + Ц₆ + Ц₇ + Ц₈ + Ц₉ + Ц =

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

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

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

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

, (2)

где n - число анализируемых количественных параметров;

aj - вес j_го параметрического индекса;

J'ТП - параметрический индекс j_го параметра.

Параметрический индекс любого нормативного (регламентируемого) параметра JНi может иметь только два значения - 0 и 1, в зависимости от того, соответствует ли данный параметр всем требуемым нормам и стандартам. Нулевое значение индекса означает полную потерю конкурентоспособности изделия.

После расчета параметрических индексов и «весов» каждого экономического параметра определяют сводный индекс конкурентоспособности по экономическим параметрам (JЭП), который выглядит следующим образом:

, (3)

где m - число анализируемых экономических параметров;

bj - вес j_го параметрического индекса;

J'ЭПj - параметрический индекс j_го параметра.

Сводные индексы конкурентоспособности по потребительным экономическим параметрам (JТП, JН, JЭП) дают интегральный показатель относительной конкурентоспособности KИ изделия по отношению к образцу. Этот показатель отражает различия между потребительными эффектами сравниваемых товаров:

(4)

Если KИ 1, анализируемое изделие превосходит по конкурентоспособности образец, если KИ 1, - уступает, если KИ = 1, - находится на одном уровне. Наша задача получить KИ 1. Это можно сделать, целенаправленно увеличивая JТП и уменьшая JЭП, улучшая соответствующие потребительские и экономические параметры изделия.

3.1.1 Порядок проведения оценки конкурентоспособности товара

Изучение рынка.

сбор данных о конкурентах

анализ проекта, оценка стоимости, определение емкости рынка и перспектив сбыта

Формулирование требований к изделию.

Определение цели анализа конкурентоспособности.

Анализ нормативных параметров.

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

выбор базового образца.

определение группового показателя конкурентоспособности по техническим параметрам и группового показателя конкурентоспособности по экономическим параметрам, анализ цены потребления

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

3.2 Оценка конкурентоспособности моделирующей системы MICROSIM

С помощью данной схемы проведем оценку конкурентоспособности рассматриваемого программного продукта.

3.2.1 Изучение рынка

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

Очевидно, что рынком реализации нашего товара является рынок программного обеспечения (ПО).

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

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

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

3.2.2 Требования к программному обеспечению

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

Распространенность аппаратно-программной платформы.

Простота обучения работе с системой.

Простота описания изучаемой модели.

Удобный интерфейс.

Продолжительность процесса моделирования.

Масштабируемость системы.

Возможность изменения параметров моделирования в процессе работы.

Цена.

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

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

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

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

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

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

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

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

3.2.3 Определение цели анализа конкурентоспособности

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

3.2.4 Анализ нормативных параметров

Прежде чем переходить к анализу нормативных параметров, остановимся на выборе базового образца. Для того чтобы в полной мере оценить характеристики системы, необходим некоторый опыт работы с ней. В следствии этого для сравнения была выбрана система моделирования GPSS фирмы Minuteman Software, как наиболее доступная для исследования.

Анализируемые параметры следует разделить на параметры, определяемые количественно и параметры определяемые качественно. Т.е. на «жесткие» и «мягкие» параметры.

К жестким параметрам можно отнести:

Распространенность аппаратно-программной платформы.

Продолжительность процесса моделирования.

Масштабируемость системы.

Возможность изменения параметров моделирования в процессе работы.

Мягкими параметрами являются:

Простота обучения работе с системой.

Простота описания изучаемой модели.

Удобный интерфейс.

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

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