4. Советы и рекомендации.

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

1. Первый вариант реализации программы.

Мы построим первый вариант в стиле “язык С с классами”. Для этоого представим каждое реляционное отношение БДВВ в виде контейнера структур – класса с набором функций - операций с ними по единому стандарту. Если сможете – сделайте шаблон “реляционное отношение” в оперативной памяти. Вариантов реализации этих классов достаточно много. Не стремитесь найти совершенство, главное - сделать просто и понятно (не обращая внимания на лишнии операции), чтобы программа работала. Не забывайте вести ЖСА разработки. Постарайтесь отразить в нем ход Ваших мыслей и принятие проектных решений до их реализации. Дело в том, что любой вариант программы имитационного моделирования на основе реаляционной модели данных будет не очень эффективен... (Почему?).

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

• Содержащих заголовки “petry.h” и реализацию “petry.cpp” классов симулятора сетей Петри и файл задачи “<task_name>.cpp” c функцией “main”.

• Исходные данные следует организовать как форматированное описание сети Петри и внешних воздействий на неё во входном файле “<task_inp>.txt”, содержащей форматированное описание статической (S, T, ST, TS - четыре отношения), динамической части (SP, TP - два отношения) и календаря событий EC.

• Результат имитационного моделирования сети Петри с заданными внешними воздействиями можно поместить в выходной файл “<task_out>.txt”, где task - имя задачи, известное функции “main”. Вы сами можете определить форму выдачи протокола состояния сети во времени.

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

• <vector> для T, S, ST, TS таблиц,

• <list> для SP, TP таблиц,

• <multimap> для календаря событий EC.

При создании контейнеров воспользуемся возможностью представления их элементов как структур - т.е. каждый кортеж – своя структура (struct – класс, члены которого всегда public). Рекомендуем следующие имена для структур кортежей с префиксом “e”:

eS, eT, eST, eTS, eSP, eTP, eEC.

Каждый контейнер-таблицу можно инкапсулировать, т.е. закрыть к нему открытый доступ, поместив его в класс с префиксом “a” и именем

aS, aT, aST, aTS, aSP, aTP, aEC.

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

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

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