Диаграммы состояний

Л Е К Ц И Й по дисциплине ВВЕДЕНИЕ

В ПРОГРАММНУЮ ИНЖЕНЕРИЮ для студентов направления 231000.62 «Программная инженерия»

Лекция 3.?. Разработка логической модели поведения программной системы.
UML-диаграммы состояний

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

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

в языке UML несколькими каноническими диаграммами, каждая из которых фиксирует

внимание на отдельном аспекте функционирования системы:
Диаграмма состояний (Statechart Diagram)
Диаграмма деятельности (Activity Diagram)
Диаграмма последовательности (Sequence Diagram)
Диаграмма кооперации (Collaboration Diagram).

которой – описание возможных последовательностей состояний и переходов между ними,

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

слабо зависит) от ее логической структуры, зафиксированной в диаграмме классов.

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

для моделирования поведения элементов модели и системы в целом. Автомат

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

автомата, являются состояние (вершина графа) и переход (дуга ориентированного графа).

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

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

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

количество состояний автомата должно быть конечным, и все они должны

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

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

Каждый переход должен обязательно соединять два состояния автомата. Допускается переход из состояния в себя, такой переход еще называют «петлей».
Автомат не должен содержать конфликтующих переходов, т. е. таких переходов из одного и того же состояния, когда объект одновременно может перейти в два и более последующих состояния (кроме случая параллельных подавтоматов). В языке UML исключение конфликтов возможно на основе введения так называемых сторожевых условий, которые будут рассмотрены ниже.
Автомат не запоминает историю перемещения из состояния в состояние. С точки зрения моделируемого поведения определяющим является сам факт нахождения объекта в том или ином состоянии, а не последовательность состояний, в результате которой объект перешел в текущее состояние. Другими словами, автомат «забывает» все состояния, которые предшествовали текущему в данный момент времени.

моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого

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

в свою очередь, может быть разделен на две секции горизонтальной

линией.
Если указана лишь одна секция, то в ней записывается только имя состояния (а); в противном случае в первой (верхней) секции записывается имя состояния, а во второй (нижней) – список некоторых внутренних действий или переходов в данном состоянии (б).
Имя состояния представляет собой строку текста, которая раскрывает содержательный смысл данного состояния (например: Звенит, Печатает, Ожидает, Занят, Свободен, Передано, Получено).
Имя состояния всегда записывается с заглавной буквы..

деятельностей (activity), которые выполняются в процессе нахождения моделируемого элемента в

данном состоянии.
Каждое из действий записывается в виде отдельной строки и имеет следующий формат: <метка-действия '/' выражение-действия>
Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, определенная выражением действия.
Выражение действия может использовать любые атрибуты и связи, которые принадлежат области имен или контексту моделируемого объекта.
Если список выражений действия пустой, то разделитель в виде наклонной черты '/' может не указываться.
Метка действия идентифицирует событие (так называемый внутренний переход), которое запускает соответствующее выражение действия.
В языке UML предусмотрены несколько фиксированных имен меток действия (следующий слайд), которые не могут использоваться в качестве имен внутренних переходов.

специфицированное следующим за ней выражением действия, которое выполняется в момент

входа в данное состояние (входное действие);
exit – эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);
do – эта метка специфицирует выполняющуюся деятельность («do activity»), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия.       В последнем случае при завершении события генерируется соответствующий результат;
include – эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата.

пользователя при аутентификации входа в некоторую программную систему.
В этом

случае список внутренних действий в данном состоянии не пуст и включает 4 отдельных действия, первые два из которых стандартные и описаны выше, а два последних определяются своей спецификацией.

состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом

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

последовательными состояниями (исходным и целевым для данного перехода), которое указывает

на факт смены одного состояния другим.
Пребывание объекта в исходном состоянии может сопровождаться выполнением некоторых действий, а переход в целевое состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. В этом случае говорят, что «переход срабатывает», или «происходит срабатывание перехода».
Переход срабатывает при наступлении некоторого события (event):
окончания выполнения деятельности (do activity);
получения объектом сообщения;
приема сигнала.
Если переход инициируется событием, происходящим асинхронно с внутренними действиями исходного состояния (например, в момент выхода из строя технического устройства или в момент окончания его ремонта), то такой переход называется триггерным.
Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого сторожевым условием.

Произошло указанное событие
и (AND ! ! !)
2. Сторожевое

условие приняло значение «истина».
Переход может быть связан с некоторыми действиями, производимыми объектом в ответ на внешние события.
На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние.
Переход может помечен строкой текста, которая описывает соответствующее событие и имеет следующий общий формат: 
<сигнатура события>'['<сторожевое условие>']' <выражение действия>.  
При этом сигнатура события описывает некоторое событие с соответствующими аргументами:
      <имя события>'('<список параметров, разделенных запятыми>')'.

в пространстве и во времени, при этом отдельные события должны

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

в прямых скобках после описания события-триггера и представляет собой некоторое

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

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

условие - это ответ на вопрос: «Пуст ли почтовый ящик клиента на почтовом сервере?». Если «Да», следует отключить соединение с провайдером, если «Нет», следует оставаться в состоянии загрузки почты

.

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

в этом состоянии программа может находиться неопределенно долго, пока пользователь ее не закроет.
После окончания активизации программа переходит в конечное состояние. В активном состоянии программы пользователь может читать сообщения электронной почты, создавать собственные послания и выполнять другие действия, не указанные явно на диаграмме.
Однако при необходимости получить новую почту, пользователь инициирует событие-триггер «установить телефонное соединение». В качестве параметра этого события выступает конкретный телефонный номер модемного пула провайдера.
Далее следует проверка сторожевого условия «телефонное соединение установлено ?», и только в случае положительного ответа происходит переход почтового клиента из состояния «активизация почтовой программы» в состояние «загрузка почты с сервера провайдера».
В противном случае (линия занята, неверный ввод пароля …) загрузки почты не произойдет, и программа останется в прежнем своем состоянии.

окончания загрузки почты на компьютер пользователя.
В этом случае событие-триггер

«закончить загрузку почты» происходит после проверки сторожевого условия «почтовый ящик на сервере пуст ?». При положительном ответе на этот вопрос (вся почта загружена или ее просто нет в ящике) почтовая программа прекращает загрузку почты и переходит в состояние активизации. В случае же отрицательного ответа загрузка почты будет продолжена.
Усложним наш пример с учетом возможности неприятного события («залипание модема»), когда вся почта с сервера загружена, а автоматический разрыв соединения не происходит.
Для реализации такой ситуации дополним нашу диаграмму еще одним переходом в целевое состояние «Активизация почтовой программы» с аналогичным событием-триггером «закончить загрузку почты», но с другим сторожевым условием «время загрузки почты превышает 600 секунд ?».

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

до начала каких бы то ни было действий в целевом состоянии;
представляет собой атомарную операцию (достаточно простое вычисление) и не может быть прервано никаким другим действием до тех пор, пока не закончится его выполнение;
может оказывать влияние как на сам объект, так и на его окружение;
записывается после знака "/" в строке текста, присоединенной к соответствующему переходу;
может содержать список отдельных действий, разделенных символом ";". Обязательное требование – все действия из списка должны четко различаться между собой и следовать в порядке их записи;
чаще всего записывается на языке программирования, который предполагается использовать для реализации модели.
В качестве примера выражения действия может служить следующая запись: «разорвать телефонное соединение (телефонный номер)»; «вывести информационное сообщение (соединение разорвано)», которое должно быть выполнено сразу после установления истинности сторожевого условия «почтовый ящик на сервере пуст ?».

состояние, которое состоит из других вложенных в него состояний. Составные

состояния называют также «суперсостояниями»
Вложенные состояния по отношению к составному называют под-состояниями (substate). Графически все вложенные состояния изображаются внутри символа составного состояния.
Составное состояние может содержать несколько параллельных подавтоматов, каждый из которых может быть представлен одним или более последовательными под-состояниями.
Любое из под-состояний, в свою очередь, может являться составным состоянием и содержать другие вложенные под-состояния. Количество уровней вложенности составных состояний в языке UML не фиксировано.

тонкие логические аспекты его внутреннего поведения.
Поведение объекта представляется последовательной сменой

его под-состояний, начиная от начального и заканчивая конечным под-состояниями.
При этом в каждый момент времени объект может находиться только в одном таком под-состоянии.
Составное состояние может содержать в качестве вложенных начальное и конечное под-состояния.
Начальное под-состояние является исходным для всего составного состояния – именно в этом под-состоянии оказывается объект после срабатывания перехода в данное составное состояние.
Переход объекта в конечное под-состояние означает завершение нахождения объекта в данном составном состоянии.
В каждом составном состоянии может быть только одно начальное и только одно конечное последовательные состояния.

объекта телефонный аппарат. Он может находиться в различных состояниях, одним

из которых является состояние дозвона до абонента.
Очевидно, для того чтобы позвонить, необходимо снять телефонную трубку, услышать тоновый сигнал, после чего набрать нужный телефонный номер. Таким образом, состояние дозвона до абонента является составным и состоит из двух последовательных под-состояний: «поднять телефонную трубку» и «набрать телефонный номер».

конечное под-состояние - нетриггерные и не помечены строками текста, описывающими

события.
Последний переход в конечное под-состояние не имеет события-триггера, но имеет сторожевое условие, проверяющее правильность набранного номера абонента. Только в случае истинности этого условия телефонный аппарат может перейти в конечное под-состояние, которое характеризует суперсостояние «дозвон до абонента» в целом.
Два оставшихся перехода – триггерные, так как инициируются асинхронными событиями - набор цифры. Такое событие имеет имя «цифра» с параметром «п» (отдельная цифра на диске телефонного аппарата.

выхода из отдельных состояний с последующим возвращением в это же

состояние с учетом той части деятельности, которая уже была выполнена на момент выхода из этого состоянии.
Для моделирования таких ситуаций в языке UML используется понятие «исторического состояния». 
Историческое состояние применяется только в контексте составного состояния и используется для запоминания того из последовательных под-состояний, которое было текущим в момент выхода из составного состояния.
На диаграммах такое состояние обозначается окружностью с буквой H внутри. Существует две разновидности исторического состояния: (а) - неглубокое (shallow history state)  и (б) – глубокое (deep  history state). В обозначении глубокого состояния к букве «H» добавляется символ «*».

состоянии, и переход извне в это составное состояние должен вести

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

только того подавтомата, к которому он относится. Другими словами, этот

тип состояния способен запомнить историю только одного с ним уровня вложенности.    Если же запомненное состояние, в свою очередь, является составным состоянием, то требуется хранить историю выходов из под-млмтояний более глубоких уровней вложенности. 
Глубокое историческое состояние (deep history state) служит для запоминания всех под-состояний любого уровня вложенности для текущего подавтомата.

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

одновременно находиться в каждом из параллельных под-состояний одного составного состояния.
Каждый из подавтоматов занимает на диаграмме некоторую область (регион) внутри составного состояния; эти области разделяются горизонтальными пунктирными линиями.

последовательных под-состояний (подавтоматы 1 и 2). В этом случае (по

определению последовательных под-состояний) в каждый момент времени объект может находиться в одном и только одном таком под-состоянии.
Для нашего примера допустимо одновременное нахождение объекта в под-состояниях (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5),
а в под-состояниях (1, 2, 3), (3, 4, 5) - НЕ допустимо.
Для каждого из вложенных параллельных подавтоматов определены собственные начальное и конечные под-состояния. При переходе в составное состояние каждый из подавтоматов оказывается в своем начальном под-состоянии, и далее все они параллельно и асинхронно выполняются вплоть до достижения каждым из них своего конечного под-состояния.
Выход из составного состояния будет возможен лишь в том случае, когда все подавтоматы будут находиться в своих конечных под-состояниях.
Если какой-либо из подавтоматов пришел в свое конечное состояние раньше других, то он должен ожидать, пока и другие подавтоматы не придут в свои конечные состояния.

составного состояния: например, подавтомат, специфицирующий составное состояние, может быть настолько

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

то такой переход называют параллельным. Параллельные переходы позволяют синхронизировать и/или

разделить отдельные параллельные под-процессы.

На рисунке представлены два составных состояния («Процесс_1» и «Процесс_2»), каждое из которых состоит из двух параллельных под-состояний.
Графически параллельный переход изображается вертикальной чертой. Если переход имеет две или более входящие дуги, то его называют соединением (join), если же он имеет две или более исходящих из него дуги, то его называют ветвлением (fork).

срабатывает в случае, если наступили события-триггеры для всех исходных состояний

этого перехода, и выполнены (при их наличии) соответствующие сторожевые условия.
При срабатывании такого перехода одновременно покидаются все исходные состояния перехода (состояния 1 и 2) и происходит переход в целевое состояние.
2. При срабатывании перехода-ветвления происходит расщепление автомата на два подавтомата, образующих параллельные под-состояния (состояния 3 и 4) составного состояния (процесс_2).
При этом моделируемый объект одновременно будет находиться во всех целевых состояниях этого перехода, и далее процесс изменения состояний будет протекать согласно ранее рассмотренным правилам для составных состояний.

состояния, обозначает переход в составное состояние (переход b), что соответствует

переходу в начальное состояние каждого из под-состояний, входящих в состав данного суперсостояния.
Переход, выходящий из составного состояния (переходы f и g), относится к каждому из вложенных под-состояний. Это означает, что объект может покинуть составное состояние, находясь в любом из его под-состояний.
Если требуется смоделировать ситуацию, когда выход из отдельного вложенного под-состояния соответствовал бы выходу и из всего составного состояния, то изображают переход, который непосредственно выходит из вложенного под-состояния за границу составного состояния (переход с).
Аналогично, допускается изображение переходов, входящих извне составного состояния в отдельное вложенное состояние (переход а).

которое называется синхронизирующим состоянием (synch state) и обозначается небольшой окружностью,

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

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

иллюстрирует все основные особенности графической нотации, используемой при построении диаграммы состояний.
Кратко прокомментируем основные особенности этого примера.
Данная диаграмма состояний представляет единственный автомат с двумя состояниями – одним простым и одним составным.
Состояние «ожидание» характеризует исправный и подключенный к телефонной сети телефонный аппарат.
Переход с атомарным действием «подать тоновый сигнал» происходит при поднятии телефонной трубки и переводит аппарат в начальное под-состояние составного состояния.

сигнал». При этом будет непрерывно издавать этот сигнал до тех

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

занят (переход в состояние «занято») либо свободен (переход в состояние

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

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

Решение этой задачи может быть реализовано на основе использования исторического состояния вместо начального под-состояния составного состояния.
В этом случае историческое подсостояние будет запоминать в памяти аппарата единожды набранный номер.
Дополнить диаграмму состояний предлагается сделать самостоятельно.

для того элемента, который имеет нетривиальное поведение в течение своего

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

не могут сработать одновременно (требование отсутствия конфликтов у переходов). Наличие

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