Лекци 11 - Кафедра анализа данных и исследования

Динамическое моделирование
На этапе динамического моделирования рассматриваются динамические, или
поведенческие, аспекты системы. Динамическая модель является одновременно
межобъектной (описывающей взаимодействие объектов) и внутриобъектной
(характеризующей, как зависящий от состояния объект определяется конечным автоматом и
изображается на диаграмме состояний). Внутриобъектная сторона динамического
моделирования имеет отношение к конечным автоматам и диаграммам состояний. Мы будем
говорить о моделировании взаимодействий объектов и о том, как использовать диаграммы состояний для описания взаимодействий зависящих от состояния объектов.
В основе построения динамической модели лежат ранее разработанные прецеденты.
Для каждого прецедента надо определить участвующие в нем объекты и то, как они общаются
в этом прецеденте. Взаимодействие графически изображается на диаграмме взаимодействия.
Следует применять один из двух видов таких диаграмм: диаграммы кооперации или диаграммы
последовательности. Необходимо также составить словесное описание взаимодействий
объектов в виде описания последовательности сообщений. Если во взаимодействии участвует
зависящий от состояния управляющий объект, то требуется разработать исполняемую им
диаграмму состояний и показать соответствующие события как на диаграмме состояний, так и
на диаграмме взаимодействий.
Моделирование взаимодействий объектов
Динамическое моделирование сильно зависит от сообщений и событий. Сообщение
- это событие вместе с данными, которые ему сопутствуют; они называются атрибутами
сообщения. Например, у события Карточка Вставлена есть два атрибута: Номер Карточки
и Срок Действия. Они считываются с магнитной полоски, которая нанесена на карточку,
вставленную в банкомат. Сообщение записывается так:
сообщение = событие (атрибуты сообщения)
допустим,
Карточка Вставлена (Номер Карточки, Срок Действия)
С событием могут и не ассоциироваться никакие данные. Так, у события Карточка
Возвращена нет атрибутов.
Имя сообщения соответствует имени события, а параметры сообщения - атрибутам.
Таким образом, в контексте диаграмм взаимодействия термины «последовательность
событий» и «последовательность сообщений» являются синонимами. Чтобы разобраться с
порядком взаимодействий между объектами, обычно приходится начинать с изучения
события; так возник термин анализ последовательности событий.
Диаграммы кооперации
Когда с помощью критериев разбиения на объекты выявлены объекты в системе,
можно приступать к изображению их динамических взаимодействий на диаграммах
кооперации.
В аналитической модели сообщения описывают информацию, транслируемую
между объектами. Диаграммы кооперации помогают идентифицировать операции
объектов, поскольку приход сообщения объекту обычно приводит к вызову одной из его
операций. Однако, основное внимание уделяется анализу передаваемой информации, а не
вызываемым операциям. На этапе проектирования мы можем предполагать, что два
разных сообщения, пришедшие объекту, вызывают разные операции или одну и ту же
операцию, которой имя сообщения передается в качестве параметра. Однако решение
следует отложить до этапа проектирования. Должно быть сообщение синхронным или
1
асинхронным, определяется в ходе проектирования. На стадии анализа все сообщения,
которыми обмениваются объекты, выглядят просто сообщениями, не более. Диаграмма кооперации разрабатывается для каждого прецедента, на ней
изображаются только объекты, участвующие в этом прецеденте. Некоторые объекты
могут присутствовать только на одной диаграмме кооперации, другие - сразу на
нескольких. Такая диаграмма описывает последовательность участия объектов в
прецеденте, для ее представления используются порядковые номера сообщении. Порядок
сообщений на диаграмме должен соответствовать той последовательности
взаимодействий между действующим лицом и системой, которая зафиксирована в
описании прецедента. Сообщения на диаграмме кооперации могут быть пронумерованы
или нет, хотя в отсутствие нумерации теряется информация об упорядочении.
Диаграммы последовательности
Диаграмму взаимодействий между объектами можно представить также в виде
диаграммы последовательности, на которой показана временная цепочка взаимодействий.
На диаграмме последовательности изображаются объекты, участвующие во
взаимодействии, и порядок отправки сообщений. Диаграммы последовательности и
диаграммы кооперации предоставляют одну и ту же информацию, но по-разному. Обычно
для описания системы используются либо те, либо другие Диаграммы, но не оба вида
сразу.
Поскольку на диаграмме последовательности сообщения, отправленные
поочередно, изображаются сверху вниз, то явно указывать их номера необязательно.
Однако в примере ниже сообщения все же пронумерованы, чтобы показать соответствие с
диаграммой кооперации.
Сравнение диаграмм последовательности и кооперации
Для изображения взаимодействий объектов и последовательности сообщений
можно использовать как диаграммы кооперации, так и диаграммы последовательности.
Диаграмма последовательности описывает порядок, в котором объекты обмениваются
сообщениями, но из нее трудно понять, как объекты связаны друг с другом. Диаграмма
кооперации, напротив, ясно показывает взаимное расположение объектов. Очередность
сообщений представлена на обеих диаграммах, Поскольку на диаграмме кооперации
порядок следования сообщений виден не так отчетливо, сообщения на ней обычно
нумеруются. Однако даже при этом условии разобраться в последовательности
сообщений, глядя на диаграмму кооперации, часто бывает нелегко. С другой стороны,
если число взаимодействующих объектов велико, то диаграмму последовательности
читать труднее. Приходится либо сжимать ее, чтобы расположить в пределах страницы,
либо размешать на нескольких страницах.
Прецеденты и сценарии
Сценарий - это один из путей обхода прецедента. Таким образом, конкретная
последовательность сообщений, изображенная на диаграмме взаимодействия, на самом
деле соответствует сценарию, а не прецеденту. Чтобы представить все описанные в
прецеденте альтернативы, часто приходится создавать несколько диаграмм
взаимодействия.
.Пользуясь условиями, на диаграммах взаимодействия разрешается изображать
альтернативы, то есть расположить весь прецедент на одной диаграмме. Однако может
оказаться, что диаграмму будет трудно читать. Поэтому на практике показывают по
одному на каждой диаграмме взаимодействия.
Обобщенные и конкретные формы диаграмм взаимодействия
2
Есть две формы диаграмм взаимодействия: обобщенные (generic) и конкретные
(istance). Конкретная форма подробно описывает один сценарий, то есть одну из
возможных последовательностей взаимодействий. Обобщенная форма показывает все
вероятные взаимодействия, может содержать циклы, ветвления и условия. Обобщенная
форма диаграммы взаимодействий применяется для указания главной и альтернативных
последовательностей прецедента. При использовании конкретной формы иногда
необходимо создавать несколько диаграмм для одного прецедента - их число зависит от
количества альтернатив. Примеры конкретных и обобщенных диаграмм взаимодействий
приведены позднее. Для всех прецедентов, кроме самых простых, диаграмма
взаимодействий обычно выглядит понятнее, если представлена в конкретной, а не
обобщенной форме. При попытке включить несколько альтернатив сложность диаграммы
резко возрастает.
В случае конкретной диаграммы последовательности время изменяется в
направлении сверху вниз. Для обобщенной диаграммы, на которой есть циклы, ветвления
и условия, это соглашение выполняется не всегда. Тем самым теряется одно из
важнейших преимуществ диаграмм последовательности.
: Устройств оСчитыв анияКарточек
: Банков скийСерв ер
2: Прочитанные с Карточки Данные
3: Карточка Встав лена
12: Прав ильный Пин-код
11: Прв ев ерить Пин-код
1: Вв од Карточки в у стройств о Считыв ания
: Карточка
: Управ лениеБанкоматом
8: Данные Карточки
7: Запрос Карточки
10: Пин-код Вв еден
4: Полу чить Пин-код
13: Выв ести меню
14: Обнов ить Состояние
6: Вв од Пин-кода
: ИнтерфейсКлиента
:
КлиентБанкомата
5: Приглашение к Вв оду Пин-кода
15: Меню операций
9: Информация от Клиента
: ТранзакцияБанкомата
1 Диаграмма сотрудничества для прецедента Проверить Пин-код
Описание последовательности сообщений
Описание
последовательности
сообщений
разрабатывается
как
часть
аналитической модели. В нем говорится, каким образом объекты аналитической модели
участвуют в прецедентах. Это текст на естественном языке, повествующий о том, что
происходит, когда сообщение приходит объекту-получателю на диаграмме кооперации
или последовательности. В описании последовательности сообщений имеются ссылки на
номера сообщений, присутствующие на диаграмме коопераций. В нем прослеживается
порядок сообщений, посланных от отправителя получателю, и рассказывается о действиях
получателя после прихода сообщения. Обычно такое описание дает дополнительную
информацию, которой нет на диаграмме кооперации объектов. Например, для каждого
3
доступа к, сущностному объекту здесь могут предлагаться сведения о том, какие атрибуты
объекта запрашиваются.
Динамический анализ
Аналитик разрабатывает прецедент, выявляя последовательность взаимодействий
(внешних событий) между действующим лицом и системой. В динамической модели этот
момент уточняется путем рассмотрения участвующих в нем объектов и очередности
внутренних событий, возникающих в результате прихода внешнего события.
Динамический анализ (его также называют анализом поведения) – это стратегия,
позволяющая разобраться в том, как объекты, представленные в аналитической модели,
взаимодействуют между собой в различных прецедентах. Динамический анализ
выполняется для каждого прецедента. Он начинается с рассмотрения внешнего события,
поступающего интерфейсному объекту, после чего прослеживается вся цепочка
внутренних событий вплоть до конечного отклика системы, При возникновении
внутренних событий происходит обмен сообщениями между объектами-участниками
прецедента. В прецеденте может быть описана последовательность внешних событий,
например, несколько взаимодействий с действующим лицом. В таком случае следует
определить цепочки внутренних событий, вызванных каждым внешним. События в
последовательности нумеруются и представляются на диаграмме кооперации. Сообщение
состоит из события и ассоциированных с ним данных.
Методика, основанная на динамическом анализе, итеративная. На первой итерации
выявляют объекты, участвующие в прецеденте, применяя критерии разбиения на объекты.
Затем определяют, как эти объекты кооперируются друг с другом для выполнения
прецедента. В ходе анализа иногда приходится задавать дополнительные объекты или
взаимодействия.
Динамический анализ может быть зависящим или не зависящим от состояния – это
определяется тем, есть ли зависимость от состояния в самом прецеденте.
В некоторых случаях производится также разбиение на подсистемы, особенно
когда следует принять во внимание географическое размещение, в частности в системах
клиент-сервер.
Динамический анализ, не зависящий от состояния
На основе прецедента делается первая попытка выявить участвующие в нем
объекты. Должен быть по меньшей мере один объект интерфейса, который получает
входные данные от действующего лица. Как правило, присутствует несколько
сущностных объектов, где содержится информация, срок хранения которой больше, чем
время исполнения данного прецедента. Несложные прецеденты могут этим и
ограничиваться. Например, в простой системе клиент-сервер прецедент состоит из
клиента, реализующего интерфейс пользователя, который взаимодействует с сервером –
сущностным объектом. В более сложных прецедентах, где есть несколько объектов,
обычно возникает потребность еще и в управляющем объекте, который координирует
взаимодействие остальных объектов. Например, управляющий объект способен
координировать выборку информации из нескольких сущностных объектов и ее
обработку до предъявления актеру с помощью объекта пользовательского интерфейса.
Не зависящий от состояния управляющий объект, например координатор или
объект таймера, необходим в тех случаях, когда нужно то или иное согласование действий
или принятие решений. Сущностный объект применяется для хранения и выборки
информации.
В случае периодических видов деятельности, в частности для генерации отчетов,
требуется вводить в рассмотрение объекты таймеров, которые активизируются событиями
таймера, в результате чего система генерирует определенную выходную информацию.
4
При этом некоторый объект должен подготовить данные (например, отчет) и послать его
интерфейсному объекту для вывода во внешнюю среду.
Стратегия выполнения не зависящего от состояния динамического анализ состоит в
том, чтобы начать с прецедента и рассмотреть по отдельности. Каждое взаимодействие
между главным действующим лицом и системой. Д.Л. начинает взаимодействие с
помощью некоторого внешнего события. Последовательность генерируемых Д.Л.
внешних событий описана в прецеденте. В простых прецедентах может быть всего одно
взаимодействие (внешнее событие), в более сложных – несколько.
Пример динамического анализа, не зависящего от состояния
В качестве примера рассмотрим прецедент Следить за Состоянием Рабочей
станции.
Имя прецедента. Следить за Состоянием Рабочей Станции.
Д.Л. Дежурный оператор.
Сводка. Прецедент описывает работу дежурного оператора, наблюдающего за
состоянием одной или нескольких рабочих станций. Предусловие. Дежурный оператор
вошел в систему.
Описание. Оператор посылает запрос на просмотр состояния одной или нескольких
рабочих станций. Каждый запрос разрешается посылать отдельно. Вместо этого оператор
может подписаться на получение извещений об изменении состояния рабочей, станции.
Альтернативы. Рабочая станция не функционирует. Оператору выводится
предупреждение. Постусловие. Выведено состояние рабочей станции.
Следить за Состоянием Рабочей Станции – это прецедент вида клиент-сервер. В
нем участвуют всего два объекта – клиент и сервер. На диаграмме взаимодействий
показан клиентский объект – Интерфейс Оператора, который посылает запрос серверному
объекту – Сервер Рабочей Станции. Последовательность сообщений выглядит так:
V1 Оператор делает запрос к сервису состояния рабочей станции, например просит
показать состояние.
V11: Объект Интерфейс Оператора посылает запрос о состоянии Серверу Рабочей
Станции.
V1.2: Сервер Рабочей Станции отвечает, посылая данные о состоянии рабочей
станции.
V1.3: Объект Интерфейс Оператора выводит оператору полученную информацию.
2
Динамический анализ, зависящий от состояния
В данном случае речь идет о взаимодействиях между объектами, которые
участвуют в прецеденте, зависящем от состояния: выходные данные, получаемые
действующим лицом, зависят не только от входных данных, но и от того, что происходило
5
в системе раньше. В прецеденте, зависящем от состояния, имеется зависящий от
состояния управляющий объект, который исполняет свою диаграмму состояний, управляя
тем самым последовательностью событий. В сложных прецедентах таких объектов
обычно несколько, и у каждого есть своя диаграмма состояний.
Определение объектов и взаимодействий
Цель динамического анализа, зависящего от состояния, - определить взаимодействия
между следующими объектами:
 зависящий от состояния управляющий объект, который исполняет диаграмму состояний;
 объекты (обычно интерфейсные), которые посылают сообщения управляющему объекту,
вызывая тем самым переходы состояний;
 объекты, представляющие действия и деятельности, которые запускают, управляющим
объектом в результате переходов состояний;
 прочие объекты, принимающие участие в прецеденте.
Взаимодействия между всеми этими объектами изображаются на диаграмме
кооперации или последовательности. По результатам анализа в ранее разработанные
диаграммы состояний вносятся изменения.
Ранее говорилось, что сообщение состоит из события и ассоциированных с ним
данных. Рассмотрим отношение между сообщениями и событиями в случае зависящего от
состояния управляющего объекта, который исполняет некоторую диаграмму состояний. Когда
такой объект получает сообщение, событие, которое является его частью, вызывает переход
состояний. Выполняемое в результате действие соответствует выходному событию,
изображенному на диаграмме кооперации. В общем случае, говоря о сообщениях, мы имеем в
виду диаграммы взаимодействия (кооперации или последовательности), а говоря о событиях
- диаграммы состояний. Однако при описании динамического сценария с зависимостью от
состояния мы будем употреблять термин «событие». Объект-отправитель посылает событие
управляющему объекту, зависящему от состояния. Поступление входного события вызывает
переход состояний. В результате этого перехода генерируется одно или несколько выходных
событий, каждое из которых управляющий объект посылает тому или иному объектуполучателю. Выходное событие на диаграмме состояний изображается в виде действия (при
переходе состояния, при входе или при выходе) либо начальной или завершающей
деятельности.
Основные шаги динамического анализа, зависящего от состояния, таковы:
 Определите интерфейсные объекты. Для этого выясните, какие объекты получают
входные данные от актера.
 Укажите зависящий от состояния управляющий объект. Существует хотя бы один
управляющий объект, который исполняет некоторую диаграмму состояний, но могут
потребоваться и дополнительные.
 Задайте прочие внутренние объекты. Речь идет о внутренних объектах, которые
взаимодействуют с управляющими или интерфейсными объектами.
 Проанализируйте кооперации объектов. Этот шаг следует выполнять вместе с шагом 5,
поскольку необходимо детально выяснить взаимодействие между управляющим
объектом и диаграммой состояния, которую он исполняет (см. следующий раздел).
 Охарактеризуйте исполнение диаграммы состояний. Данный шаг описывается в
следующем разделе.
 Рассмотрите альтернативные последовательности. Проведите зависящий от состояния
динамический анализ альтернативных последовательностей прецедента.
6
Пример динамического анализа, зависящего от состояния: банковская
система
В качестве примера рассмотрим абстрактный прецедент Проверить ПИН-код,
взятый из банковской системы. Объекты, принимающие в нем участие, определяются с
помощью критериев разбиения на объекты, изложенных ранее.
Главная последовательность
Проанализируем абстрактный прецедент Проверить ПИН-код. В нем описывается,
как клиент вставляет карточку в устройство считывания, как система запрашивает ПИНкод и затем проверяет, совпадает ли указанный клиентом ПИН-код с тем, который
хранится в базе данных для этого номера карточки. Сценарий, соответствующий случаю,
когда карточка действительна и ПИН-код введен правильно, представлен на диаграмме
кооперации (см. рис. 1) и на диаграмме последовательности (см. рис. 3).
При разборе прецедента становится очевидной необходимость в объекте
Интерфейс Устройства Считывания Карточек. Информацию, считанную с карточки,
требуется где-то хранить, поэтому нужен сущностный объект Карточка. Объект
Интерфейс Клиента используется для реализации взаимодействия с клиентом с помощью
клавиатуры и дисплея - в данном случае для запроса ПИН-кода. Информация, которую
нужно послать подсистеме Банковский Сервер для проверки ПИН-кода, хранится в
объекте Транзакция Банкомата. В ее состав должен входить введенный ПИН-код и номер
карточки. Для управления последовательностью действий понадобится управляющий
объект Управление Банкоматом, который будет исполнять заданную диаграмму
состояний.
Прецедент начинается, когда клиент вставляет карточку в устройство считывания.
Нумерация сообщений идет с 1, этот номер присваивается первому внешнему событию,
инициированному актером. Следующие номера соотносятся с объектами в системе,
реагирующими на это событие: 1.1,1.2,1.3 и, наконец, 1.4.
Последний номер присвоен отклику системы, который показан актеру на экране.
Следующему внешнему событию, инициированному актером, присвоен номер 2 и т.д.
В описании последовательности сообщений ниже указаны все сообщения на
диаграммах кооперации и последовательности (см. рис. 1 и 3). Сообщение, полученное
объектом Управление Банкоматом, приводит к переходу состояний в его диаграмме
состояний (см. рис. 4). Очередность сообщений такова:
1: Клиент Банкомата вставляет карточку в Устройство Считывания карточек.
Данные с карточки считываются объектом Интерфейс Устройства Считывания Карточек.
1.1: Объект Интерфейс Устройства Считывания Карточек отправляет Данные
Карточки, включающие идентификатор карточки и срок действия сущностному объекту
Карточка.
1.2: Интерфейс Устройства Считывания Карточек посылает событие Карточка
Вставлена объекту Управление Банкоматом. Это приводит к переходу из состояния
Простаивает (начального) в состояние Ожидание ПИН-кода. С этим переходом
ассоциировано действие Получить ПИН-код, которое на диаграмме состояний
соответствует выходному событию Получить ПИН-код на диаграммах кооперации и
последовательности.
1.3: Объект Управление Банкоматом посылает событие Получить ПИН-код объекту
Интерфейс Клиента.
1.4: Объект Интерфейс Клиента выводит Приглашение к Вводу ПИН-кода актеру
Клиент Банкомата.
2: Клиент Банкомата вводит ПИН-код в объект Интерфейс Клиента.
2.1 Интерфейс Клиента запрашивает Данные Карточки у объекта Карточка.
2.2:Объект Карточка передает Данные Карточки объекту Интерфейс Клиента.
7
2.3: Интерфейс Клиента отправляет Информацию о Клиенте, содержащую
идентификатор карточки, ПИН-код и срок действия карточки, сущностному объекту
Транзакция Банкомата.
2.4: Интерфейс Клиента посылает событие ПИН-код Введен (Данные о Клиенте)
объекту Управление Банкоматом. Это вызывает переход последнего из состояния
Ожидание ПИН-кода в состояние Проверка ПИН-кода. С данным переходом
ассоциировано выходное событие Проверить ПИН-код.
2.5: Объект Управление Банкоматом передает запрос Проверить ПИН-код (Данные
о Клиенте) объекту Банковский Сервер.
2.6: Банковский Сервер проверяет ПИН-код и возвращает объекту Управление
Банкоматом ответ Правильный ПИН-код. При получении этого с бытия объект
Управление Банкоматом переходит в состояние Ожидание Выбора Клиента. С таким
переходом связано два описанных ниже выходных события.
2.7: Объект Управление Банкоматом посылает событие Вывести Меню объекту
Интерфейс Клиента.
5 Диаграмма состояний Проверить ПИН-код
2.7а: Объект Управление Банкоматом отправляет сообщение Обновить Состояние
объекту Транзакция Банкомата.
2.8: Объект Интерфейс Клиента выводит актеру Клиент Банкомата меню с
операциями «Снять деньги», «Получить справку» и «Перевести деньги».
Альтернативные последовательности
Далее мы рассмотрим альтернативные последовательности в прецеденте Проверить
ПИН-код, При описании главной последовательности в предыдущем разделе
предполагалось, что карточка действительна и ПИН-код введен правильно. Теперь
посмотрим на ветви, соответствующие недействительной карточке и неправильно
введенному ПИН-коду. Их можно выявить на основе раздела «Альтернативы» в описании
прецедента. Рассмотрим сообщение Проверить ПИН-код, посылаемое Банковскому
Серверу (сообщение 2.5). Возможны различные ответы. В точке, где происходит
разделение, каждая ветвь помечается своей заглавной буквой, то есть альтернативны
ответы на сообщение 2.6 будут нумероваться так; 2.6А, 2.6В и 2.6С.
Выделяются следующие альтернативы:
8
 карточка действительна, ПИН-код введен правильно. Этот случай соответствует
главной последовательности и описывается условием [Правильный]: 2.6:
[Правильный]: Правильный ПИН-код Банковский Сервер посылает сообщение
Правильный ПИН-код;
 введен неправильный ПИН-код. Данная альтернатива описывается условием
[неправильный]: 2.6А* [Неправильный]: Неправильный ПИН-код. В таком случае
Банковский Сервер посылает сообщение Неправильный ПИН-код. Повторный запрос
порождает группу сообщений с номерами от 2.6А.1 до 2.6А.8;
 неправильный ПИН-код введен три раза подряд. Эта альтернатива описывается
условием [Три Неудачи]: 2.6В [Три Неудачи]: Третий неверный ПИН-код. В таком
случае Банковский Сервер посылает сообщение Третий неверный ПИН-код;.
 карточка украдена или закончился срок ее действия: 2.6С [Украдена ИЛИ
Закончилась]: Карточка Украдена, Истек Срок Действия.
Какова бы ни была причина, последовательность сообщений одна и та же, а результат
- конфискация карточки.
9
10
11
4
12
Описание последовательности сообщений для прецедента «Снять
Деньги на Клиенте»
Здесь приводятся сообщения, показанные на диаграмме кооперации. Вместе с тем
указываются соответствующие состояния и переходы на диаграмме состояний банкомата.
Нумерация сообщений продолжает начатую в описании прецедента Проверка ПИН-код на
Клиенте:
3: Актер Клиент Банкомата отмечает в Интерфейсе Клиента операцию «Снятие
денег» и вводит номер чекового или сберегательного счета и сумму.
3.1: Интерфейс Клиента посылает информацию о выбранной операции объекту
Транзакция Банкомата.
3.2: Объект Транзакция Банкомата возвращает Детали Транзакции, то есть ид
Транзакции, ид Карточки, ПИН-код, дату, время, номер Счета и сумму.
3.3: Интерфейс Клиента направляет запрос Выбрано Снятие (Детали Транзакции)
объекту Управление Банкоматом, вызывая переход последнего в состояние Обработка
Снятия. С этим переходом ассоциированы два выходных события: Запрос на Снятие и
Вывести «Ждите».
3.4: Объект Управление Банкоматом передает транзакцию Запрос на Снятие,
содержащую Детали Транзакции, объекту Банковский Сервер.
3.4а: Объект Управление Банкоматом посылает сообщение Вывести «Ждите»
объекту Интерфейс Клиента.
3.4а1: Интерфейс Клиента выводит Сообщение «Ждите» объекту Клиент
Банкомата.
3.5: Банковский Сервер посылает ответ Снятие Успешно (Детали Снятия ) объекту
Управление Банкоматом. Объект Детали Снятия содержит подлежащую выдаче сумму и
баланс счета. Это событие вызывает переход объекта Управление Банкоматом в состояние
Выдача. Одновременно генерируются события Выдать Наличные и Обновить Состояние.
3.6: Объект Управление Банкоматом отправляет сообщение Выдать На личные
(Детали Суммы) объекту Интерфейс Устройства Выдачи Н личных.
3.6а: Объект Управление Банкоматом выдает сообщение Обновить Со стояние
(Детали Снятия) объекту Транзакция Банкомата.
3.7: Интерфейс Устройства Выдачи Наличных сообщает Снимаемую Сумму
объекту Наличные Банкомата.
3.8: Объект Наличные Банкомата посылает положительный Ответ о снятии объекту
Интерфейс Устройства Выдачи Наличных.
3.9: Интерфейс Устройства Выдачи Наличных командует внешнему Устройству
Выдачи Наличных выдать клиенту наличные.
3.10: Интерфейс Устройства Выдачи наличных отправляет событие Наличные
Выданы объекту Управление Банкоматом, в результате чего последний переходит в
состояние Печать. С этим переходом ассоциированы три события: Печатаь Чек, Вывести
«Наличные выданы» и Подтверждение Выдачи Наличных.
3.11: Объект Управление Банкоматом посылает событие Печатать Чек объекту
Интерфейс Устройства Печати Чеков
3.11а. Объект Управление Банкоматом просит Интерфейс Клиента вывести
сообщение «Наличные выданы».
3.11а.1: Интерфейс Клиента выводит сообщение «Наличные выданы» Клиенту
Банкомата.
3.11b: Объект Управление Банкоматом передает Подтверждение Выдачи Наличных
объекту Банковский Сервер.
3.12: Интерфейс Устройства Печати Чеков запрашивает Данные о Транзакции у
объекта Транзакция Банкомата.
13
3.13: Объект Транзакция Банкомата посылает Данные о Транзакции объекту
Интерфейс Устройства Печати Чеков.
3.14: Интерфейс Устройства Печати Чеков направляет внешнему устройству
Печати Чеков выводимые данные.
3.15: Интерфейс Устройства Печати Чеков посылает событие Чек Напечатан
объекту Управление Банкоматом, в результате чего тот переходит в состояние Возврат. С
этим переходом ассоциировано выходное событие Вернуть.
3.16: Объект Управление Банкоматом выдает событие Вернуть объекту Интерфейс
Устройства Считывания Карточек.
3.17: Интерфейс Устройства Считывания Карточек командует внешнему
Устройству Считывания Карточек.
3.18: Интерфейс Устройства Считывания Карточек отправляет co6ытие Карточка
Возвращена объекту Управление Банкоматом, вызывая тем самым переход в состояние
Завершен. С переходом связано выходное событие Вывести «Карточка возвращена».
3.19: Объект Управление Банкоматом посылает событие Вывести «Карточка
возвращена» объекту Интерфейс Клиента.
3.20: Интерфейс Клиента выводит сообщение «Карточка возвращена» Клиенту
Банкомата.
14
15
16