Разработка подсистемы управления проблемами распределенной системы управления телекоммуникационными услугами на базе платформы CPN TOOLS для Ставропольского филиала ОАО "ЮТК"
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
ент времени
В позиции Users DB хранятся фишки, содержащие данные о пользователях (рисунок 4.6).
Рисунок 4.6 - Маркировка позиции Users DB в начальный момент времени
В позиции Problems DB хранятся записи о проблемах (рисунок 4.7).
Рисунок 4.7 - Маркировка позиции Problems DB в начальный момент времени
Таким образом, позиции Client, Devices и Users PC являются входными позициями системы. Позиция Users DB хранит данные обо всех пользователях, имеющих доступ к подсистеме управления проблемами. Позиция Problems DB в начальный момент времени содержит информацию обо всех уже известных проблемах. Все остальные позиции в исходном состоянии не содержат фишек.
Выполним трассировку модели.
Возьмём одну фишку из позиции Client и переместим её в позицию Users PC, при этом выполнится переход Set priorety, который установит приоритет, а также сформирует запрос (рисунок 4.8).
Рисунок 4.8 - состояние модели после одного шага
Одна из фишек переместилась в позицию Users PC, при этом изменив свой цвет на r, также изменилась и временная метка фишки. Так как временная метка этой фишки увеличилась, она не может перемещаться, пока модельное время не сравняется с её временной меткой. Теперь возьмём другие фишки из позиции Users PC и переместим их в позицию request (рисунок 4.9).
Рисунок 4.9 - состояние модели после трёх шагов
Теперь в позиции request находятся две фишки, у которых после перехода Identification Autontification временные метки равны 3. Переместим оставшиеся в позиции Client фишки в позицию Users PC. Теперь переместим фишки из позиции Devices в позицию Diag. dev., при этом выполнится переход Transaction to diag. dev., который ничего не делает, но нужен для передачи информации о проблемах от оборудования до устройств диагностики (рисунок 4.10).
Рисунок 4.10 - состояние модели после семи шагов
Затем переместим фишки из позиции Diag. dev. в позицию Problem, при этом выполнится переход Select priorety, который установит приоритет проблем в зависимости от их типов, а также увеличит временные метки фишек (рисунок 4.11).
Рисунок 4.11 - состояние модели после девяти шагов
Теперь текущее модельное время равно 1, а количество выполненных шагов - 9. Таким образом, теперь можно переместить фишку, которая использовалась самой первой. После этого переместим одну из фишек из позиции Problem позицию Saving info, при этом, в зависимости от того, найдено решение в базе данных или нет, выполнится переход Answer found (рисунок 4.12) или Answer found (рисунок 4.13). У фишки, которая пройдёт через переход Answer found изменится поле решения. Также оба перехода увеличивают временную метку фишки на 10, это время необходимо для поиска информации в базе данных проблем.
Рисунок 4.12 - состояние фишки после перехода Answer found
Рисунок 4.13 - состояние фишки после перехода Answer not found
Переместим фишку из позиции request через переход Request for solve. Этот переход выполнит сохранение информации об уже решённой проблеме в базу данных (рисунок 4.14), а также отправит фишку в позицию Solved, которая является выходной позицией модели (рисунок 4.15).
Рисунок 4.14 - сохранение информации о проблеме в базу данных
Рисунок 4.15 - Выходная позиция Solved
Теперь выполним переход Request for report (рисунок 4.16).
Рисунок 4.16 - состояние фишки после перехода Request for report
Затем выполним переход Request for problem, который извлечёт из запроса проблему (рисунок 4.17).
Рисунок 4.17 - состояние фишки после перехода Request for problem
Переведём в эту же позицию и остальные фишки, соответствующие запросу о новой проблеме. Затем переведём фишки через переход Save info (рисунок 4.18), который выполнит сохранение информации о проблеме в базу данных и увеличит временные метки фишек на 3.
Рисунок 4.18 - состояние фишек после перехода Saving info
Затем фишка, для которой было найдено решение, сможет пройти через переходы transmit1 и solve, а также через промежуточную позицию Answer и попадёт в выходную позицию Solved. Фишка же, для которой не было найдено решение, переместится через переход Increase priorety, который увеличит приоритет фишки, а также увеличит её временную метку на 1, в позицию Problem with new priorety (рисунок 4.19).
Рисунок 4.19 - состояние фишки после перехода Increase priorety
Затем эта фишка через ничего не делающий переход transmit2 попадает в позицию Searching for answer, а оттуда в переход tr, который выполняет эмуляцию действий пользователя, случайным образом решая проблему. Оттуда фишка поступает в позицию Splitter (рисунок 4.20).
Рисунок 4.20 - состояние фишки после перехода tr
Затем, в зависимости от того, была проблема решена пользователем или нет, она поступает или в переход Solved problem, который сохраняет информацию о проблеме в базу данных и передаёт фишку в выходную позицию Solved, или в переход Unsolved problem, который формирует запрос, подставляя из базы данных имя и пароль нужного пользователя, после чего отправляет проблему на второй уровень (рисунок 4.21).
Рисунок 4.21 - состояние проблемы после поступления на второй уровень
&n