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

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

1. Анализ организации данных первого варианта.

Почему реляционная модель данных оказывается не рчень эффективной в процессе выполнения приложений? Главных причины этого две. Первая – связи между экземплярами реляционных отношений (образующих реляционную базу данных задачи) поддерживаются “по значению” в полях одноименных атрибутов. Оказывается, что такая связь подразумевает поиск совпадающих значений, что не очень эффективно. Правда, мы можем использовать индексы, но это требует дополнительную память и в конечном итоге создает свои сложности (например, проблема тождественности отношения и его индексов в операциях обносления). Вторая причина неэффективности – есть продолжение первой. Напомним, что структура реляционной базы данных определяется только функциональными зависимостями между атрибутами. Следовательно, мы не учитываем при этом особенностей и требований алгоритма решения конкретной задачи. В объектных базах данных ситуация не такая жесткая. Поэтому объектное представление данных в процессе выполнения приложения оказывается более эффективным. Но каких либо однозначных советов и рекомендаций на этот счет авторы UML & RUP не дают (слишком велико многообразие задач).

2. Как построить объектную базу данных.

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

Итак, в нашей задаче главное понятие – активность места-перехода. А если быть ещё более точным – начало и конец каждого отдельного процесса работы места-перехода. Именно здесь мы описываем причину и следствие (т.е. связь захваченных и сброшенных меток-ресурсов) во времени. Отметим, что в реляционной модели “причин и следствий” просто нет. Если в терминах объектной базы данных нам удастся хорошо поддержать указанные выше понятия, то можно надеяться на её эффективность.

5. Порядок выполнения работы.

Настоящая версия лаб.раб. использует для отладки пример описания проблемной ситуации из лаб.раб.№01.01.00. Если он слишком большой, то надо выбрать его часть для представления в виде сети Петри на одном уровне. Отладочный пример не должен содержать более чем 10 мест (состояний и переходов). Но слишком простой – не позволит полноценно отладить программу.

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

1. Вариант “С++ с классами”.

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

Используйте рекомендации, но попытайтесь самостоятельно написать (как угодно, если не знаете STL) и отладить программу имитационного моделирования. Она Вам вполне по силам. Файлы с отлаженным примером скопировать и сохранить (до экзамена). Очень важно, чтобы Вы вели ЖСА разработки в режиме «протоколирования хода мысли». Это поможет Вам самоорганизоваться и в сложных случаях будет подсказкой в «работе над своими ошибками».

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