Контейнер кортежей: вектор и список.
Библиотека STL (входящая в стандарт языка C++ ISO/IEC 14882 1998г.) позволяет использовать несколько вариантов шаблонов контейнеров. Мы ограничимся двумя из них: вектором и двусвязанным списком. Преимущество первого – прямой доступ по времени к любому элементу за фиксированное время, для второго типа контейнера очень просто реализуются операции “добавить” и “удалить” кортеж. Отметим, что поиск кортежа в обоих контейнерах по значению поля атрибута имеет линейную оценку (т.е. реализован как простой перебор). Для доступа к элементам используется итератор. Идея поддержки реляционного отношения очень простая, надо только сформировать структуру или класс кортежа отношения (они будут начинаться с префикса “с”- строчная) и инстанцировать необходимый контейнер с итератором к нему. Ниже даны примеры организации циклов.
class cT { public; string TN; int TD; };
vector< cT > trans;
vector< cT >::iterator i;
struct cEC { string TN; time TK;};
list< cEC > evcal;
list< cEC >::iterator j;
...
for(i=trans.begin(); i != trans.end(); ++i)
{ for(j=state.begin(); j != state.end(); ++j)
if((*i).TN == (*j).TN) { // нашли значение
...
}
// нет значения
...
} // оценка затрат осталась преждней...
Остается два вопроса, на который надо дать ответы. Во-первых не всегда экземпляр реляционного отношения может целиком уместиться в оперативной памяти. Во-вторых, нам надо организовать чтение экземпляров реляционных отношений из ИБД программного комплекса в приложение. Оба вопроса не вызывают затруднений (если не учитывать эффективность реализации приложения). Но для имитационных задач положение дело обстоит как раз наоборот (особенно для моделей высоких размерностей).
Новая парадигма объектов.
Новыми объектами можно считать всю сеть Петри целиком, статическую часть сети Петри (отношения “S”,“T”,“ST”,“TS”), описание внешних воздействий (протокол, т.е. реляционное отношение «SP») и протокол активности переходов “ТP”. Особое место занимает реляционное отношение «ЕC». В начальный и конечный моменты времени оно пустое. Это отношение используется как промежуточное, собственное реляционное отношение процесса имитации для хранения только текущих активных мест-переходов. Объектом хранения во внешней памяти (т.е. в ИБД) оно станет только тогда, когда мы изменим трактовку задачи (например, станим хранить части процесса имитационного моделирования).
Полагаем, что в любом представлении данных для программного приложения всегда можно выделить следующие подмножества данных как объекты с точки зрения приложения:
Исходное описание модели исследуемого объекта;
Модель и описание внешних воздействий на исследуемый объект;
Временные (собственные) данные процесса имитационного моделирования;
Результаты имитационного моделирования объекта.
Технология поддержки связей.
Если мы имеем дело с програмированием, то объекты как экземпляры одного класса всегда имеют некоторое выделенное им пространство (за исключением абстрактных классов объектов). Желаем мы того или нет, но это приводит к некоторой адресации полей памяти для представлений объектов. Поэтому можно считать, что почти всегда мы имеем дело с набором полей. Другой вопрос, односвязанный или нет этот набор. Основными видами связей между двумя односвязанными наборами полей памяти наших объектов мы будем полагать следующие типы связей:
Е - эквивалентность (взаимнооднозначное соответствие элементов), что порождает постоянное смещение между полями (односвязанные поля элементов);
О - “один к одному” (несвязанные, служебные поля поддерживают петлю связей);
М - “один ко многим” (несвязанные, служебные поля поддерживают петели прямой и обратной связи для каждой пары элементов).
Если таблица отношения организована контейнером-вектором, то предпочтительной является ссылка на его элемент в виде индекса (не изменняется при перемещении поля вектора). При использовании контейнера-списка ссылка на его элемент должна быть физическим адресом. Можно описать варианты поддержки связей более детально, но пока мы не будем этого делать, а построим объектную базу данных для примера сети Петри.