3. Входной язык – описание сети Петри.

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

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

aS, aT, aST, aTS.

4. Входной язык.

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

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

5. Трассировкапри имитации.

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

6. Особенности реализации событийного механизма.

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

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

2. О варианте “ООП в С++”.

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

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