UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Рис. 21.7. Конечный автомат класса Loan имеет простой узел слияния 482 Глава 21. Конечные автоматы 21.6.2. Ветвление переходов – псевдосостояние выбора Для представления простого ветвления без слияния необходимо ис пользовать псевдосостояние выбора (choice pseudo state), как показано на рис. 21.9. Псевдосостояние выбора направляет поток конечного автомата соглас но заданным условиям. Псевдосостояние выбора позволяет направлять поток конечного авто мата согласно условиям, заданным для исходящих переходов. Напри OnLoan Overdue T erminated [after maximumDuration] returnBook узел слияния и ветвления Loan returnBook FineDue payFine [extend] [!extend] Рис. 21.8. Конечный автомат класса Loan имеет узел слияния и ветвления Unpaid FullyPaid PartiallyPaid OverPaid [payment > balance] [payment < balance] acceptPayment acceptPayment makeRefund BankLoan псевдосостояние выбора [payment = balance] Рис. 21.9. Реализация ветвления без слияния с помощью псевдосостояния выбора 21.7. События 483 мер, на рис. 21.9 показан поведенческий автомат простого класса Bank Loan (банковская ссуда). При получении события acceptPayment (принят платеж) объект BankLoan переходит из состояния Unpaid (не оплачен) в одно из трех состояний – FullyPaid (полностью оплачен), OverPaid (пере плачен) или PartiallyPaid (частично оплачен) – в зависимости от соотно шения объема платежа ( payment) и неоплаченного баланса BankLoan. Условия, налагаемые на исходящие переходы псевдосостояния выбо ра, должны быть взаимоисключающими, чтобы гарантировать в лю бой момент времени срабатывание только одного из них. 21.7. События События инициируют переходы. UML определяет событие как «описание заслуживающего внимания происшествия, занимающего определенное положение во времени и пространстве». События инициируют переходы в автоматах. События могут быть указаны вне состояний на переходах, как на рис. 21.10, или внутри состояний, как на рис. 21.11. Существует четыре семантически различных типа событий: • событие вызова; • сигнал; • событие изменения; • событие времени. 21.7.1. События вызова Событие вызова (call event) – это запрос на вызов конкретной операции экземпляра контекстного класса. Событие вызова – это запрос на вызов конкретной операции. Сигнатура события вызова должна быть аналогичной сигнатуре опера ции контекстного класса автомата. Получение события вызова – это Off On событие turnOff turnOn Рис. 21.10. События указаны вне состояний на переходах 484 Глава 21. Конечные автоматы триггер на выполнение операции. Таким образом, событие вызова – вероятно, самый простой тип событий. В примере на рис. 21.11 показан фрагмент конечного автомата класса SimpleBankAccount (простой банковский счет). На данный класс наложе ны следующие ограничения: • баланс счетов всегда должен оставаться большим или равным нулю; • запрос на снятие денег будет отклонен, если запрашиваемая сумма превышает баланс. На рисунке показаны внутренние и внешние события вызова. Они со ответствуют операциям класса SimpleBankAccount. Для события вызова может быть задана последовательность действий, в которой действия перечисляются через точку с запятой. Они опреде ляют семантику операции и могут использовать атрибуты и операции контекстного класса. Если у операции есть возвращаемый тип, собы тие вызова имеет возвращаемое значение этого типа. 21.7.2. Сигналы Сигнал – это однонаправленная асинхронная связь между объектами. Сигнал – это пакет информации, асинхронно передаваемый между объектами. Сигнал моделируется как отмеченный стереотипом класс, содержащий в своих атрибутах информацию, которая должна быть пе редана (рис. 21.12). У сигнала обычно нет операций, потому что он предназначен только для передачи информации. InCredit deposit(m)/ balance = balance + m AcceptingWithdrawal entry/ balance = balance m RejectingWithdrawal entry/ logRejectedWithdrawal() withdraw(m) [balance < m] withdraw(m) [balance >= m] внутреннее событие вызова действие условие внешнее событие вызова входное действие SimpleBankAccount close() Рис. 21.11. Внутренние и внешние события вызова 21.7. События 485 На рис. 21.13 представлен скорректированный конечный автомат для SimpleBankAccount. Теперь при отклонении запроса на снятие денег со счета посылается сигнал. Передача сигнала обозначается выпуклым пятиугольником, внутри которого указывается имя сигнала. Такой же синтаксис используется на диаграммах деятельностей (см. раздел 15.6, где сигналы обсуждаются более подробно). Прием сигнала обозначается вогнутым пятиугольником, как показано во фрагменте конечного автомата на рис. 21.14. В нем указана опера ция контекстного класса, которая принимает сигнал как параметр. «signal» RejectedWithdrawal date : Date accountNumber : String requestedAmount : double availableBalance : double Рис. 21.12. Сигнал – это класс, отмеченный стереотипом «signal» InCredit deposit(m)/ balance = balance + m AcceptingWithdrawal entry/ balance = balance m RejectingWithdrawal entry/ logRejectedWithdrawal() withdraw(m) [balance < m] withdraw(m) [balance >= m] SimpleBankAccount close() RejectedWithdrawal посылка сигнала Рис. 21.13. Посылка сигнала Позвонить клиенту processRejectedWithdrawal( a : RejectedWithdrawal ) контекст: класс Bank прием сигнала Рис. 21.14. Прием сигнала 486 Глава 21. Конечные автоматы Прием сигнала также можно показать на внешних или внутренних пе реходах с помощью стандартной нотации имяСобытия/действие, которая обсуждалась в разделах 21.5.1 и 21.6. 21.7.3. События изменения События изменения имеют место, когда значение логического выраже ния меняется с false на true. Событие изменения задается в виде логического выражения, как по казано на рис. 21.15. Ассоциированное с событием действие выполня ется, когда логическое выражение меняет значение с false на true. Все значения логического выражения должны быть константами, гло бальными переменными или атрибутами и операциями контекстного класса. С точки зрения реализации событие изменения означает по стоянную проверку логического условия при нахождении в опреде ленном состоянии. На рис. 21.15 конечный автомат SimpleBankAccount был изменен таким образом, что менеджер получает уведомление, если баланс счета ста новится равным или большим 5000. Это уведомление необходимо для того, чтобы менеджер мог предупредить клиента о других вариантах вклада. События изменения являются срабатывающими по положительному фронту (positive edge triggered). Это означает, что они инициируются при каждом изменении значения логического выражения с false на true. InCredit deposit(m)/ balance = balance + m balance >= 5000 / notifyManager() AcceptingWithdrawal entry/ balance = balance m RejectingWithdrawal entry/ logRejectedWithdrawal() withdraw(m) [balance < m] withdraw(m) [balance >= m] SimpleBankAccount close() RejectedWithdrawal логическое выражение Рис. 21.15. Событие изменения в виде логического выражения 21.8. Что мы узнали 487 Чтобы событие изменения было инициировано, логическое выражение должно вернуться к значению false, а затем снова перейти к true. Срабатывание по положительному фронту – это именно то поведение, которое требуется для класса SimpleBankAccount. Действие notifyManager() (уведомить менеджера) будет инициироваться, только когда баланс счета достигнет 5000 или превысит эту сумму. Понятно, что если ба ланс будет колебаться вокруг 5000, менеджер получит множество уве домлений. Мы предполагаем, что у менеджера есть некоторый бизнес процесс для обработки такой ситуации. 21.7.4. События времени События времени происходят в ответ на время. События времени обычно обозначаются ключевыми словами when (ко гда) и after (после). Ключевое слово when определяет конкретное время, когда событие инициируется; after определяет порог времени, после ко торого событие инициируется. Например: when(date = 07/10/2005) и af ter(3 months). На диаграмме для каждого события времени обязательно должны быть указаны единицы измерения времени (часы, дни, месяцы и т. д.). Все символы выражения должны быть константами, глобальными пе ременными или атрибутами и операциями контекстного класса. Пример на рис. 21.16 – это фрагмент автомата класса CreditAccount, имеющего ограниченные (несколько суровые) условия получения кре дита. Как видите, если объект CreditAccount находится в состоянии Over drawn (кредит превышен) в течение трех месяцев, он переходит в состоя ние Frozen (заморожен). 21.8. Что мы узнали В этой главе обсуждалось построение простых конечных автоматов с по мощью состояний, действий, деятельностей, событий и переходов. Мы узнали следующее: Overdrawn Frozen after( 3 months ) контекст: класс CreditAccount Рис. 21.16. Фрагмент автомата класса CreditAccount с ограничением по времени 488 Глава 21. Конечные автоматы • Конечные автоматы основаны на работе Харела. • Конечные автоматы моделируют динамическое поведение реак тивного объекта. • Диаграммы состояний содержат единственный конечный авто мат одного реактивного объекта. • Реактивный объект обеспечивает контекст конечного автомата. • Реактивные объекты: • отвечают на внешние события; • могут генерировать внутренние события; • имеют четкий жизненный цикл, который может быть смоде лирован как последовательность состояний, переходов и со бытий; • имеют текущее поведение, которое может зависеть от преды дущего. • Примеры реактивных объектов: • классы (самые распространенные); • прецеденты; • подсистемы; • целые системы. • Существует два типа конечных автоматов: • поведенческие автоматы: • моделируют поведение контекстного классификатора; • состояния в поведенческих автоматах могут содержать нуль или более действий и деятельностей; • протокольные автоматы: • моделируют протокол контекстного классификатора; • состояния в протокольных автоматах не имеют действий и деятельностей. • Действия – мгновенные и непрерываемые части работы: • могут иметь место в состоянии и быть ассоциированными с внут ренним переходом; • могут иметь место вне состояния и быть ассоциированными с внешним переходом. • Деятельности – части работы, которые занимают конечный проме жуток времени и могут быть прерваны: • могут иметь место только в состоянии. • Состояние – семантически значимое состояние объекта. • Состояние объекта определяется: • значениями атрибутов объекта; • отношениями с другими объектами; 21.8. Что мы узнали 489 • деятельностями, осуществляемыми объектом. • Синтаксис состояния: • входное действие – осуществляется немедленно при входе в состояние; • выходное действие – осуществляется немедленно при выходе из состояния; • внутренние переходы – обусловливаются событиями, недоста точно существенными для инициации перехода в новое со стояние: • событие обрабатывается внутренним переходом в рамках состояния; • внутренняя деятельность – часть работы, которая занимает конечный промежуток времени и может быть прервана. • Переход – перемещение между двумя состояниями. • Синтаксис перехода: • событие – событие, инициирующее переход; • сторожевое условие – логическое выражение, которое долж но выполниться, чтобы переход произошел; • действие – действие, которое происходит вместе с переходом; • переходное псевдосостояние – объединяет или разветвляет переходы; • псевдосостояние выбора – направляет поток конечного авто мата согласно наложенным условиям. • Событие – что то существенное, происходящее с реактивным объ ектом. Типы событий: • событие вызова: • вызов необходимого набора действий; • вызов операции объекта; • сигнал: • прием сигнала – сигнал это асинхронная однонаправленная связь между объектами; • событие изменения: • имеет место, когда некоторое логическое условие меняет свое значение с false на true (т. е. ребро инициируется при переходе ложь истина); • событие времени: • ключевое слово after – происходит по прошествии некоторого промежутка времени; • ключевое слово when – происходит, когда выполняется неко торое временное условие. 22 Дополнительные аспекты конечных автоматов 22.1. План главы Эту главу мы начинаем с обсуждения составных состояний. Это со стояния, содержащие вложенный конечный автомат. В разделе 22.2 22.6. Что мы узнали изучаем типы составных состояний изучаем состояния подавтоматов изучаем взаимодействие подавтоматов изучаем предысторию 22.2. Составные состояния 22.2.1. Простые составные состояния 22.2.2. Ортогональные составные состояния 22.3. Состояния подавтоматов 22.4. Взаимодействие подавтоматов 22.5. Предыстория 22.5.1. Неглубокая предыстория 22.5.2. Глубокая предыстория Рис. 22.1. План главы 22.2. Составные состояния 491 вводится понятие вложенных конечных автоматов, или подавтоматов. Затем обсуждаются два типа составных состояний – простое составное состояние (22.2.1) и ортогональное составное состояние (22.2.2). В раз деле 22.3 мы рассматриваем, как можно с помощью состояний подав томатов показать конечные автоматы, представленные на других диа граммах. При наличии двух или более параллельных подавтоматов между ними часто необходимо установить некоторое взаимодействие. Это обсужда ется в разделе 22.4. Здесь вводится стратегия взаимодействия, в кото рой используются значения атрибутов контекстного объекта. В разделе 22.5 вводится понятие предыстории, заключающееся в запо минании суперсостоянием своего последнего подсостояния перед ис ходящим переходом. В разделах 22.5.1 и 22.5.2 обсуждаются два вида предыстории – неглубокая и глубокая. 22.2. Составные состояния Составные состояния содержат один или более вложенных подавтоматов. Составное состояние – это состояние, содержащее вложенные состоя ния. Эти вложенные состояния объединяются в один или более конечных ав томатов, которые называют подавтоматами (submachines). Для каж дого подавтомата в пиктограмме композиции отведена собственная об ласть . Области – это просто участки пиктограммы состояния, разде ленные пунктирными линиями. Простой пример областей представ лен на рис. 22.2. Вложенные подсостояния наследуют все переходы содержащих их су персостояний. Вложенные состояния наследуют все переходы состояний, в которые они входят. Это очень важный момент. Если, например, у самого со ставного состояния есть определенный переход, каждое из вложенных в него состояний тоже имеет этот переход. Составное состояние A B C область 1 область 2 подавтомат 1 подавтомат 2 Рис. 22.2. Каждому подавтомату отведена своя область 492 Глава 22. Дополнительные аспекты конечных автоматов Конечное псевдосостояние подавтомата относится только к его облас ти . Таким образом, если подавтомат области 1 в примере на рис. 22.2 достигает своего конечного состояния первым, эта область завершает ся, а область 2 продолжает выполнение. Если необходимо завершить выполнение всего составного состояния, можно использовать терми нальное (terminate, завершающее) псевдосостояние, как показано на рис. 22.3. В этом примере все составное состояние завершается при достижении терминального псевдосостояния. Вложенные состояния также могут быть составными состояниями. Однако, как правило, необходимо по возможности стремиться к тому, чтобы вложенность составных состояний не превышала двух или трех уровней. При большей глубине вложенности автомат сложно воспри нимать на диаграмме и понимать. Для сохранения ясности и простоты диаграммы состояний иногда не обходимо скрывать детали составного состояния. Показать, что состоя ние является составным, можно без явного отображения его структу ры, добавив пиктограмму композиции (composition icon). Это необяза тельное дополнение, но очень полезное для обозначения того, что у со стояния есть составные части, поэтому мы рекомендуем постоянно им пользоваться. Пиктограмма композиции приведена на рис. 22.4. В зависимости от количества областей выделяют два типа составных состояний. 1. Простое составное состояние – только одна область. 2. Ортогональное составное состояние – две или более областей. Эти типы составных состояний рассматриваются в двух следующих подразделах. Составное состояние D E F терминальное псевдосостояние Рис. 22.3. Терминальное псевдосостояние Составное состояние пиктограмма композиции Рис. 22.4. Пиктограмма композиции указывает, что состояние составное 22.2. Составные состояния 493 22.2.1. Простые составные состояния Простые составные состояния содержат всего один вложенный конеч ный автомат. Простое составное состояние – это составное состояние, содержащее всего одну область. Например, на рис. 22.5 показан автомат для класса ISPDialer (модем). Этот класс отвечает за подключение к провайдеру Ин тернета. Состояние DialingISP – простое составное состояние, потому что оно имеет всего одну область. В этом конечном автомате есть не сколько интересных моментов. |