Skip to content

ООП Лекция 16. ДПС и ТПС.

Vladislav Mansurov edited this page Jun 5, 2022 · 1 revision

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

Чем может характеризоваться поведение? Мы четко выявляем, что объекты за срок своей жизни проходят через какие-то определенные стадии. Рождение, детство, отрочество, юность... То, как эволюционирует объект между стадиями, характеризует черту поведения этого объекта. Любой объект в данный момент времени находится в какой-то стадии.

Объект переходит из одной стадии в другую скачкообразно. Например, у нас есть два состояния: сон и бодрствование. Мы не можем сразу перейти, и у нас есть стадия просыпания, то есть мы спим, просыпаемся и бодрствуем.

Не все переходы из одной стадии в другую возможны.

В физическом мире происходят инциденты:

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

Модель Мура

Для описания поведения объектов мы используем модель Мура.

Она включает в себя:

  • множество состояний объекта (стадий)
  • множество инцидентов которые переводят объект из одной стадии в другую (событий)
  • множества действий, которые мы связываем с состоянием
  • правила перехода

Что из себя представляет модель состояния? Мы ее можем оформить либо диаграммой, либо таблицей.

Не во все состояния мы можем перейти, исходя из текущего.

Диаграмма переходов состояний (ДПС)

ДПС - диаграмма переходов состояний. Состояние на этой таблице рисуется прямоугольником.

image

Состояния

Каждому состоянию мы присваиваем:

  • уникальный номер
  • имя состояния.

Виды состояния:

  • Состояние создания - такие состояния, в которых объект появляется первый раз. Переход в такие состояния переходит не из состояния.

  • Заключительное состояние. Возможно два варианта заключительных состояний:

    • Объект уничтожается. Это состояние на диаграмме рисуется пунктирной линией.

      image

    • Состояние, из которых объект уже не переходит в другие состояния. Дальнейшего поведения у объекта нет, но он не уничтожается! На диаграмме оно рисуется таким же прямоугольником, но перехода из него в другое нет.

      image

  • Текущее (промежуточные) состояние. Чтобы определять текущее состояние, мы в класс добавляем вспомогательный атрибут, который определяет это состояние. Его называют статусом.

Пример Лампочки

image

Имеет два состояния: выкл. и вкл. Чтобы объект перешел из одного состояние в другое объект должно произойти событие, как внутренне, так и внешнее. Событие переносят данные, какие данные? Обязательно это идентификатор объекта, кроме событие создания.

Из состояние выкл переходим в вкл, событие Л1 => происходит событие лампочка включается. Например Л2, лампочка выключается.

Описание события:

  • Значение события - короткое событие, отвечающее на вопрос: "Что происходит?".
  • Предназначение события. Мы четко событие связываем с каким-либо объектом.
  • Метка события (номер).
  • Данные события. Событие может переносить данные. Данные могут быть причем двух типов: идентифицирующие данные и любые другие атрибуты, причем не обязательно только того объекта, для которого происходят события.

Правила связи события с состоянием

  • Все события, которые переводят объект в определенное состояние, должны нести одни и те же данные. С каждым состоянием мы связываем действие, которое должно выполняться при переходе объекта в состояние.
  • Правило состояния создания: то событие, которое переводит в состояние создания, не несет идентификатора объекта.
  • Правило состояния не создания: оно должно нести обязательно идентификатор объекта.

Действия

Теперь по поводу действия. Каждому состоянию мы ставим в соответствие действие. Задача действия - перевести объект в то состояние, которому оно соответствует. Что делает действие? Оно может выполнять любые операции над атрибутами самого объекта. Кроме того, выполнять любые вычисления. Действие может порождать события для любого объекта любого класса, в том числе и для самого себя. В том числе порождать события для чего-либо вне области анализа нашей подсистемы. выполнять любые действия над таймером: выполнять создавать считывать, запускать таймер, очищать таймер.

Мы не накладываем ограничений. Действие имеет доступ к любым атрибутам объектов любых классов. На этом этапе мы не ограничиваем действие! Ограничения возникнут позже.

Что обязано действие:

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

Алгоритм действия можно разместить на ДПС непосредственно под самим состоянием, если оно короткое. Описание действия - псевдокод (как правило, используют псевдокод аля Паскаль). Если алгоритм большой - выносим его с ДПС.

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

Таблица переходов состояний (ТПС)

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

image

Варианты заполнения ячеек:

  • В какое состояние объект перейдет в результате возникновения события в этом состоянии? В ячейке пишем номер состояния, в которое переходит объект.
  • У нас может быть ситуация, когда событие игнорируется, то есть в этом состоянии объект игнорирует событие. Событие происходит - никакого перехода не происходит. В этом случае мы ставим прочерк.
  • Еще одно возможное заполнение ячейки (лучше чтобы их не было) - данное событие не может произойти, если объект находится в этом состоянии. Ставим крестик (не плюсик).

Анализ по таблице переходов состояния - все ячейки должны быть заполнены.

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

Пример ДПС и ТПС на примере таймера

Есть какой-то таймер. Как наш таймер будет работать? Есть время для таймера, и когда таймер запускается - идет обратный отсчет нашего времени. Если время равняется нулю, таймер подает событие. Нам нужна метка события и объект, для которого порождается событие

Выделяем следующие состояния:

  • установка таймера,
  • отсчет времени (понятно, что в обратном порядке),
  • подача сигнала (когда время стало равное нулю),
  • сброс.

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

Установка таймера может быть из состояния сброса. Мы задаем таймер. Ключевой таймер + номер события и что делаем - устанавливаем таймер (какой таймер установить, время, метка события и id объекта). Показываем на диаграмме.

Из установки таймера мы можем перейти к отсчету времени, а можем сбросить. Назовем событие Т6 тиком - отсчетом времени, оно несет с собой идентификатор таймера.

Отсчет времени. Тик произошел. Но не факт, что оно стало нулем, поэтому еще раз нужно подать событие Т6 (из 2 в 2).

Можем ли мы во время отсчета времени сбросить таймер? Можем... А когда время стало равным нулю, мы переходим в состояние подачи сигнала. Подаем сигнал, и после подачи сигнала идет сброс таймера.

Вот мы получили жизненный цикл таймера!

Что касается действия. Какое действие может поместиться здесь? Время может быть установлено нулем? Если время = 0, то порождаем...

image

image

if т.статус = 1 or т.статус = 2 then
    т.статус := 2;
    т.время := т.время - 1;
    if т.время != 0 then
        породить T7: Подать сигнал(т.Idt)
    else
        породить Т6. Тип произошёл (т.Idt)
    end if
end if;

Небольшое подведение итогов

На информационной модели мы выделили атрибуты, характеристики объектов. Выделяя модель состояний, мы рассматривали поведение объектов, как они меняют свое состояние. В общем, это всё входит в идею белого ящика - мы рассматриваем наши объекты изнутри: выделили характеристики и поведение.

Когда мы выделяем состояние, надо четко помнить, что у каждого состояния есть какая то цель: зачем нам нужно это состояние?

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

Для каких объектов мы формируем жизненный цикл

Для каких объектов мы формируем жизненный цикл? Лучше всего модель поведения свести к суперклассу. Но подклассы могут иметь свои жизненные циклы...

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

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

Когда мы выделяем жизненные циклы или формируем модель поведения

Для пассивных объектов мы не выделяем жизненные циклы, но иногда делаем в интересах активных объектов.

Объекты спецификаций - жизненные циклы не выделяются (расписание дня, движения поездов).

Если это задача или запрос - выделяем.

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

Если объект создается поэтапно - да (состояния стройки).

Любое оборудование, которое имеет четкое выделяемое состояние (любой бытовой прибор).

Анализ отказа

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

Почему это произошло?

Своевременность происхождения этого события? Важно проанализировать, что все события порождаются, и кто эти события порождает.

К атипичному поведению системы мы должны относиться так же, как к типичному. Лифт ехал и застрял. Если мы начнем обрабатывать это как исключительную ситуацию, лифт будет уничтожен...Это ненормально. Мы должно добавлять новый жизненный цикл, соответствующий этому состоянию, добавляя новые состояния, соответствующие этим типичным атипичным ситуациям.

Clone this wiki locally