Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ванеев О.Н. МУ к ЛР5 по ТИПИС.doc
Скачиваний:
0
Добавлен:
21.08.2019
Размер:
139.26 Кб
Скачать

14

Федеральное агентство по образованию

Государственное образовательное учреждение

высшего профессионального образования

"Кузбасский государственный технический университет"

Кафедра информационных и автоматизированных

производственных систем

Моделирование процессов обмена данными

Методические указания по выполнению лабораторной

работы по курсу "Теория информационных процессов и систем" для студентов специальности 071900 дневной формы обучения

Составители О. Н. Ванеев

Утверждены на заседании

кафедры

Протокол № 5 от 9.11.2005

Рекомендовано к печати учебно-

методической комиссией

по специальности 071900

Протокол № 74 от 30.11.2005

Электронная копия находится в

библиотеке главного корпуса

ГУ КузГТУ

Кемерово 2006

  1. Цель работы

Изучение принципов обмена управляющей информацией.

В связи с этим, содержанием работы являются:

  • изучение принципов передачи информации между объектом и элементом системы.;

  • изучение принципов программной реализации обмена информацией;

2. Теоретические положения

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

Задача усложняется, когда состав элементов системы переменен. В этом случае управляющий элемент не может заранее знать адресов объектов, в которые должна быть направлена управляющая информация.

В данном случае взаимодействие элементов системы с управляющим элементом может быть построено по следующему принципу. Управляемые элементы, в случае, если им требуется управляющее воздействие, сами направляют в управляющий элемент событие-требование, в котором, передаются

  • данные элемента, выработавшем требование и

  • данные о своем состоянии, на основании которых должно выработаться управляющее воздействие.

Управляющий элемент производит обработку полученного требования и выдает управляющее воздействие по адресу, взятому из требования.

Обработка требований производится по одному. При этом управляющий элемент проходит состояний, соответствующие этапам обработки. У управляющего элемента можно выделить следующие этапы:

Ожидание требования;

Обработка требования и выработка воздействия.

При этом, в состоянии обработка и выработка воздействия управляющий элемент не может принять другие требования, он для них закрыт. Так как обработка производится с большой скоростью, то для управляемых объектов данные состояния управляющего объекта не заметны.

В системе в данном случае можно выделить два класса объектов

класс TUOb соответствующий управляющему объекту;

класс TOb соответствующий управляемому объекту.

Класс соответствующий управляемому объекту должен объекту включать следующими атрибутами

1. id_Ob

2.uo

3.IdSost

Где id_Ob идентификатор объекта.

uo – в данном параметре запоминается управляющий объект, который управляет данным объектом. Тип данного параметра должен соответствовать типу, определенному для управляющего объекта. Значение данному параметру должно присваивается, когда для управляемого объекта определяется его управляющий объект. В том случае, если управляющий объект не меняется, этот параметр можно задавать при создании управляемого объекта.

IdSost – идентификатор состояния это описывающий атрибут, используемый для того, чтобы определить состояние объекта, данный атрибут в модели может заменяться другими атрибутами, комбинацией их значений.

В модели состояний управляемого объекта должно выделяться, по крайней мере, 2 состояния.

  1. Состояние выработки события, соответствующего требованию управляющего воздействия.

  2. Состояние, в которое объект переводится под действием управляющего воздействия события Ob_Ob1.

Таблица описания состояний объекта Ob

Обозна-

чение

состо-

яния

Значение

состояния

Значения

атрибутов

Выполняемые действия

Оb1

Выработка требования управляющего воздействия

uUOb = внешней переменной определенной для управляющего объекта.

Вырабатывается событие управляющего объекта

uo.UOb_ UOb 2(self)

Выполнение данного действия повторяется.

*Требуется таймер.

О2

Событие U_U2 это событие управляющего объекта.

Таблица описания событий объекта O

Обозна-

чение

события

Значение

События

Действия выполняемые событием

Данные события

Оb_Оb2

Перевод объекта из состояния требования управления следующее состояние

Выключается таймер или переключается на другое действие.

В качестве данных может передаваться информация, определяющая параметры состояния Оb2

Описание класса, сделанное на основе информационной модели и модели состояний приведено в прил.1.

В определении класса управляемого объекта метка l1 введена для визуализации объектов класса.

Таймер t1 служит для обеспечения выполнения периодических действий (действие, выполняемое в состоянии O1 выполняется периодически, как отмечено в описании состояний).

Параметр конструктора U:TUOb введен для задания управляющего объекта, связанного с данным объектом.

Описание программной реализации методов объекта класса O также приведено в приложении.

Класс TUO, соответствующий управляющему объекту должен обладать, по крайней мере, следующими атрибутами

1. Ou

2.IdSost

Где,

Ou – в данном атрибуте запоминается управляемый объект, тип данного атрибута должен соответствовать типу определенному для управляемого объекта. Значение данному параметру должно присваиваться, когда управляющий объект получает событие-требование от управляемого объекта. Данные об управляемом объекте передаются в выработанном им событии.

IdSost – идентификатор состояния, это описывающий атрибут, используемый для того, чтобы определить состояние управляющего объекта.

В модели состояний управляющего объекта должно выделяться, по крайней мере, 2 состояния.

  • UO1 Состояние ожидание получения требования управляющего воздействия.

  • UO1 Состояние выработки управляющего воздействия Ob_Ob1.

Таблица описания состояний объекта UOb

Обозна-

чение

состо-

яния

Значение

состояния

Значения

атрибутов

Выполняемые действия

UOb1

Ожидание

Требования управления

Ou = nil, то есть объект управления не определен.

Действий не выполняется.

UOb2

Выработка управляющего воздействия

Ou<> nil

Вырабатывается событие Ou.Ob_Ob2(..)

Событие Ob_Ob2 это событие управляемого объекта. Оно переводит его в состояние, следующее за состоянием «требование управления»

Таблица описания событий объекта UOb

Обозна-

чение

события

Значение

События

Действия выполняемые событием

Данные события

Uob_Uob2

внешнее

Перевод объекта из состояния ожидания требования управления в следующее состояние

В качестве значение атрибута Ou заносится объект, данные о котором переданы с событием.

В качестве данных передается указание на объект, требующий управления.

Описание класса управляющего объекта (класс TUO), сделанное на основе информационной модели и модели состояний приведено в прил.1.

Описание программной реализации методов объекта класса классf TUO также приведено в приложении.

В случае, если управление одного объекта зависит от данных других объектов у управляющего объекта может быть добавлено еще одно состояние, в котором он сравнивает данные от объекта, требование от которого захвачено с данными остальных объектов, то есть принимаются события - требования других объектов.

При этом, если необходимы данные любого произвольного объекта (например, для формирования пары объектов), то захватывается первое требование и происходит переход к следующему состоянию.

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

В случае необходимости анализа требований других объектов модель состоянии будет выглядеть следующим образом.