Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 90

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

Если срабатывает датчик вторжения, блок сигнализации воспроизводит тревогу вторжения в течение 15 минут, после чего системавозвращается в исходное состояние Monitoring. Это регулируется местным законодательством.2. Если в ходе воспроизведения тревоги вторжения возникает пожар,происходит немедленный переход из состояния SoundingIntruderAlarmв состояние SoundingFireAlarm и начинает звучать сигнал пожарнойтревоги. Это означает, что пожарная тревога всегда имеет более высокий приоритет, чем тревога вторжения.Initializing и Monitoring – составные состояния. Развернутый вид составного состояния Initializing представлен на рис. 22.7.496Глава 22. Дополнительные аспекты конечных автоматовBurglarAlarmSystemSystemActiveSoundingIntruderAlarmdeactivatefireSoundingFireAlarmintruderfireMonitoringafter(15 mins)SystemInactiveInitializingsensorErroractivateoffofferrorHandlingErrorРис.

22.6. Автомат системы сигнализацииПри входе в это состояние происходит ветвление и начинается параллельное выполнение двух подавтоматов. В верхнем подавтомате состояние InitializingFireSensors выполняет процесс инициализации пожарных датчиков. В нижнем подавтомате состояние InitializingSecuritySensors делает то же самое для датчиков безопасности.В нормальных условиях по завершении обоих подавтоматов происходитавтоматический выход из суперсостояния Initializing. Это объединение:подавтоматы синхронизируются таким образом, что дальнейшая работаневозможна, пока не будут инициализированы и пожарные датчики,и датчики безопасности.

Конечно, продолжительность инициализацииДетали составного состояния InitializingInitializingInitializingFireSensorsdo/ initializeFireSensorInitializingSecuritySensorsdo/ initializeSecuritySensorРис. 22.7. Развернутый вид составного состояния Initializing49722.2. Составные состояниязависит от используемых типов датчиков, но в простейшем случае этоможет быть просто короткая задержка на «разогрев» приборов.Из состояния Initializing также есть переход sensorError (ошибка датчика) (рис. 22.6), наследуемый обоими подсостояниями. Он позволяетнемедленно выйти из Initializing при возникновении ошибки датчика.Также составное состояние Initializing и все его подсостояния наследуют переход off от своего суперсостояния SystemActive (система активна).Он обеспечивает возможность немедленного выхода из Initializing (и всехподсостояний SystemActive) при получении события off.Иногда требуется запустить параллельные потоки управления, которые не надо синхронизировать с помощью объединения по их завершении.

Этот вариант представлен составным состоянием Monitoring, показанным на диаграмме состояний на рис. 22.8. У этого состояния естьнекоторые интересные свойства.• Два подавтомата не синхронизируются:• При возникновении события fire осуществляется явный переходот MonitoringFireSensors в выходное псевдосостояние fire, при этомпроисходит выход из состояния Monitoring. Подавтомат MonitoringFireSensors завершается, но подавтомат MonitoringSecuritySensorsпродолжает выполнение.• Аналогично при возникновении события intruder осуществляетсяявный переход от MonitoringSecuritySensors в выходное псевдосостояние intruder, при этом происходит выход из суперсостоянияMonitoring.

Подавтомат MonitoringSecuritySensors завершается, ноподавтомат MonitoringFireSensors продолжает выполнение.• Составное состояние Monitoring и все его подсостояния (рис. 22.8) наследуют переход off от своего суперсостояния SystemActive, представленного на рис. 22.6. Это обеспечивает системе возможность немедленно завершить работу в ответ на событие off независимо от того,какое из подсостояний является активным.Детали составного состояния MonitoringMonitoringMonitoringFireSensorsfiredo/ monitorFireSensorMonitoringSecuritySensorsdo/ monitorSecuritySensorРис.

22.8. Составное состояние Monitoringintruder498Глава 22. Дополнительные аспекты конечных автоматовЭтот пример показывает, как использование параллельных составныхсостояний, с синхронизацией или без нее, позволяет очень эффективно моделировать параллелизм.22.3.

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

Поведение описывается на одной диаграмме,и затем при необходимости просто делается ссылка на эту диаграмму.Например, пусть две очень похожие системы охранной сигнализацииимеют некоторое сходное поведение. Это поведение можно описать наотдельной диаграмме, а затем в автоматах каждой системы ссылатьсяна эту диаграмму с помощью состояний подавтоматов.Состояния подавтоматов именуются следующим образом:имя состояния : имя используемой диаграммы состоянийНа рис. 22.9 представлена диаграмма состояний, описывающая поведение, которое используется в другой диаграмме. Обратите внимание,что входное и выходное псевдосостояния можно показать на рамке.VerifyingUserLoggingIngetDetailsGettingDetailscanceldo/ getUsernamedo/ getPasswordverifyDetailsVerifyingdo/ getUsernamedo/ getPasswordcancelledverified[badUsername][badPassword]Рис.

22.9. Диаграмма состояний автомата VerifyingUserbadUsernamebadPassword49922.4. Взаимодействие подавтоматовИх также можно поместить внутрь рамки, но нам кажется, что размещение на рамке более четко отображает их суть как точек входа и выхода конечного автомата.Сослаться на автомат VerifyingUser (верификация пользователя) можнос помощью состояния подавтомата, как показано на рис. 22.10.

Состояние подавтомата названо verifyingCustomer (верификация клиента).Читая эту диаграмму, состояние подавтомата необходимо мысленнозаменять содержимым диаграммы VerifyingUser.CheckingOutсостояние подавтоматаverifyingCustomer : VerifyingUsercancelledcancelledCancellingCheckoutbadUsernameverificationFailedbadPasswordDisplayingError[ok]verifiedgetDetailsverifyDetails[noDetails]succeededAcceptingPayment[!ok]paymentFailed[details]checkOutAssessCustomerРис.

22.10. Ссылка на автомат VerifyingUser с помощью состояния подавтомата22.4. Взаимодействие подавтоматовНа рис. 22.7 было показано, как можно использовать ветвления и объединения для создания и последующей синхронизации параллельныхподавтоматов. Это вид синхронного взаимодействия подавтоматов –параллельные подавтоматы ожидают завершения друг друга, пока всеони не закончат выполнение.Однако очень часто необходимо обеспечить взаимодействие подавтоматов, но без синхронизации автоматов. Это называют асинхроннымвзаимодействием.В UML асинхронное взаимодействие может быть обеспечено с помощью «сообщений», или «флагов», оставляемых одним подавтоматомво время выполнения. Другие подавтоматы могут подбирать эти флаги, когда будут готовы.500Глава 22.

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

Аналогично некоторые платежи могут быть более или менеесрочными (по кредитной карте, например), а для прохождения другихможет потребоваться несколько рабочих дней (по чеку, например). Однако здесь действует бизнесправило, выстраивающее логическую зависимость между двумя подавтоматами: заказ не может быть доставлен, пока не будет укомплектован и оплачен.OrderProcessingAcceptingPaymentPaidFordo/ acceptPaymentAssemblingOrderentry/ paidFor = true[paidFor]DeliveringOrderdo/ assembleOrderРис. 22.11.

Параллельное выполнение подавтоматовВ верхнем подавтомате на рис. 22.11 по завершении состояния AcceptingPayment осуществляется переход в состояние PaidFor, где атрибутуpaidFor присваивается значение true. В нижнем подавтомате, когда завершается AssemblingOrder, можно осуществить переход к DeliveringOrder,но только когда атрибут paidFor принимает значение true. Мы добилисьасинхронного взаимодействия двух подавтоматов с помощью атрибута, выступающего в роли флага, значение которого задается одним подавтоматом, а запрашивается другим. Это простой и широко используемый механизм.

И наконец, оба подавтомата завершаются и синхронизируются, и мы покидаем состояние OrderProcessing.22.5. ПредысторияПри использовании автоматов в моделировании часто сталкиваешьсясо следующей ситуацией.• Вы находитесь в подсостоянии A составного состояния.22.5. Предыстория501•Переходите из составного состояния (и, следовательно, из подсостояния A).• Проходите через одно или более внешних состояний.• Возвращаетесь в составное состояние, но хотели бы продолжить выполнение в подсостоянии A с того момента, на котором остановились в прошлый раз.Как можно добиться этого? Понятно, что составному состоянию необходим какойто способ для запоминания подсостояния, в котором вынаходились при выходе из него. Это требование возвращения к тому,на чем остановились, настолько распространено, что специально дляего реализации в UML было включено псевдосостояние предыстории.Предыстория позволяет суперсостоянию при возвращении после прерывания «начинать с того, на чем остановился».С помощью предыстории суперсостояния запоминают последнее активное подсостояние.