Лекция 08-3 (примеры моделирования без учета

Технология разработки
программного обеспечения
Реализация вариантов использования
(без учета состояний)
Динамическое моделирование
• Два вида динамического моделирования
1. Моделирование не учитывающее
состояние объектов.
2. Моделирование учитывающее состояние
объектов (зависимое от состояния).
Моделирование динамического
взаимодействия не учитывающее
состояние объектов
Моделирование динамического
взаимодействия без учета состояния
• При моделировании динамического
взаимодействия без учета состояния
выполняются следующие основные шаги.
1. Разработка модели варианта использования.
2. Определение объектов, которые требуются для
реализации данного ВИ.
2a. Определение интерфейсных (граничных) объектов.
2b. Определение внутренних программных объектов.
3. Определение основной очередности обмена
сообщениями (в основной последовательности ВИ).
4. Определение альтернативной очередности обмена
сообщениями.
1. Разработка модели варианта
использования
• Для динамического моделирования нужно рассмотреть
взаимодействие между основным актером и
разрабатываемой системой.
• Следует помнить, что актер начинает взаимодействие с
системой с помощью внешнего устройства ввода.
• Система отвечает на введенные данные выполнением
некоторых действий, а затем, обычно, предоставляет
некоторые выходные данные.
• Последовательность ввода данных актером и ответов
системы описывается в варианте использования.
• Разработка описания такой последовательности
взаимодействия начинается с описания основного
последовательности ВИ (основного потока событий).
• Рассматривается каждое взаимодействие в анализируемой
последовательности между актером и системой.
2. Определение объектов, которые
требуются для реализации данного ВИ
• На данном шаге используются критерии
применяемые при структуризации объектов,
требуемых для реализации рассматриваемого
ВИ.
• Выделяются следующие объекты:
– интерфейсные (граничные) объекты (шаг 2a);
– внутренние программные объекты (шаг 2b).
Шаг 2a: выделение интерфейсных
(граничные) объектов
• Рассматривается актер (или актеры), участвующие в данном ВИ.
• Определяются внешние объекты (внешние для системыe)
посредством которых данный актер взаимодействует с системой.
• Определяются программные объекты, которые получают данные
введенные данным актером.
• Начинается рассмотрение данных вводимых внешними объектами
в систему.
• Для каждого события внешнего ввода данных, рассматриваются
программные объекты, которые требуются для обработки данного
события.
• Определяются требуемые программные интерфейсные объекты
(такие, как объекты ввода данных или объекты взаимодействия с
пользователем), которые получают входные данных от внешнего
объекта.
• На основе полученных внешних данных, интерфейсный объект
выполняет некоторую процедуру их обработки и обычно
отправляет сообщение какому-то внутреннему объекту.
Шаг 2б: выделение внутренних
программных объектов
• Рассматривается основная
последовательность ВИ.
• С помощью критерия структуризации
объектов выполняется первая попытка
определения внутренних программных
объектов, которые принимают участие в
данном ВИ, таких, как сущностные объекты и
управляющие объекты.
3. Определение основной очередности
обмена сообщениями
• Для каждого события ввода данных от внешнего
объекта рассматривается передача сообщений
между
– интерфейсным объектом, который получает
сообщение о вводе данных (input event) и
– другими объектами (сущностными и управляющими),
которые взаимодействуют между собой для
обработки рассматриваемого события.
• Рисуется диаграмма взаимодействия, которая
показывает объекты, участвующие в данном ВИ и
последовательности сообщений между ними.
• Данная последовательность обычно
– начинается с внешнего ввода данных актером (внешним
объектом),
– после чего следует последовательность внутренних
сообщений между участвующими программными
объектами, до вывода данных актеру (внешнему объекту).
• Данный процесс повторяется для каждого
последующего взаимодействия между актером (или
актерами) и системой.
• В результате такого описания может потребоваться
участие дополнительных объектов и дополнительных
обменов сообщениями, для которых должны быть
заданы номера очередности их выполнения.
4. Определение альтернативной
последовательности обмена сообщениями
• Рассматриваются разные альтернативы, такие,
как обработка ошибок, которые описываются
в разделе «Альтернативный поток событий» в
рассматриваемом ВИ.
• Затем рассматриваются объекты, которые
должны участвовать при выполнении
альтернативных ветвей и определяется
последовательность сообщений между ними.
Примеры моделирования
динамического взаимодействия без
учета состояния
Примеры моделирования
• Рассмотрим два примера моделирования
динамического взаимодействия без учета
состояния:
1. с использованием ВИ «Просмотр состояния
датчиков» («View Alarms»).
2. с использованием ВИ «Система подачи заказа»
(«Make order request»).
Пример 1: построение
динамической модели для ВИ «View
Alarms»
Пример 1: построение динамической
модели для ВИ «View Alarms»
• В качестве примера моделирования
динамического взаимодействия без учета
состояния рассмотрим ВИ «Просмотр состояния
датчиков» («View Alarms»), разработанный для
«Системы Контроля за Аварийными
Ситуациями».
• Диспетчер запрашивает у системы показать
текущее состояние датчиков.
• В данном примере выполняются ранее
описанные 4 шага динамического
моделирования, описанные ранее, хотя в связи с
тем, что данный пример очень простой, то в нем
нет альтернативных последовательностей.
1. Разработка модели варианта
использования
• В ВИ «Просмотр состояния датчиков» («View Alarms»)
имеется только один актер «диспетчер» (monitoring
operator), который может запрашивать просмотр
состояния аварийных датчиков, как показано ниже:
Описание варианта использования
• Имя ВИ: Просмотр состояния датчиков
• Актер: Диспетчер
• Краткое описание: Диспетчер просматривает состояния
датчиков и узнает причину аварийного состояния.
• Предусловие: Диспетчер должен войти в систему.
• Основная последовательность:
1. Диспетчер запрашивает просмотр интересующих его
датчиков.
2. Система показывает состояние датчиков.
• Для каждого датчика система показывает
–
–
–
–
имя датчика
описание датчика,
расположение датчика,
уровень опасности (высокий, средний, низкий).
• Постусловие: Показано состояние интересующих его
датчиков.
2. Определение объектов, которые
требуются для реализации данного ВИ
• Т.к. ВИ «Просмотр состояния датчиков» («View
Alarms») это простой ВИ, то в нем участвует только два
объекта.
• Эти объекты могут быть определены в результате
внимательного чтения описания ВИ.
• В данном случае объектами являются:
1. интерфейсный объект взаимодействия с
пользователем, называемый «Operator Interaction»,
который получает запросы от актера и посылает
результирующие данные актеру;
2. сервисный объект, называемый «Alarm Service», который
предоставляет доступ к хранилищу состояний датчиков и
отвечает на запросы о состоянии датчиков.
Диаграмма коммуникации
• Диаграмма коммуникации для ВИ «Просмотр
состояния датчиков» («View Alarms»).
3. Определение последовательности
передачи сообщений
• Диаграмма коммуникации для данного ВИ показывает
объект взаимодействия с пользователем «Объект
взаимодействия с диспетчером», который делает запрос к
сервисному объекту «Сервис состояния датчиков «Alarm
Service», который возвращает требуемую информацию.
• Данная последовательность сообщений соответствует
последовательности взаимодействий между актером и
системой, описанной в данном ВИ.
• Она м.б. описана следующим образом:
A1: Диспетчер (Monitoring Operator) делает запрос к сервису
работающему с датчиками (alarm handling service) –
например, просмотр состояния датчиков или подписка на
получение аварийных сообщений конкретного типа.
Данный запрос отправляется объекту взаимодействия с
оператором «Operator Interaction».
Пример 2: построение
динамической модели для ВИ
«Система подачи заказа»
Пример 2: построение динамической модели для
ВИ «Выполнение запроса на заказ товаров»
• Пример из ориентированной на сервисы системы онлайн торговли.
• Диаграмма ВИ «Выполнение запроса на заказ товаров»
(Make Order Request) показана ниже:
1. Разработка модели варианта
использования
• В ВИ «Выполнение запроса на заказ товаров»
(Make Order Request)
– актер – клиент вводит информацию запроса на
выполнение заказа;
– затем система получает информацию об учетной
записи данного клиента и запрашивает
авторизацию кредитной карты данного клиента.
– если кредитная карта авторизуется, то система
создает новый заказ на доставку и показывает
данный заказ.
Описание варианта использования
• Имя ВИ: Выполнение запроса на заказ
• Краткое описание:
– Клиент вводит запрос на выполнение заказа на покупку
товаров в он-лайн системе торговли.
– Кредитная карта клиента проверяется на достоверность и
достаточное количество денег, чтобы оплатить
запрашиваемые товары из каталога.
• Актер: Клиент
• Предусловие: Клиент выбрал один или более товар из
каталога.
• Основная последовательность: [описана далее].
• Альтернативная последовательность: [описана далее].
• Постусловие: Система создает заказ на доставку
товаров клиенту.
Основная последовательность событий
1. Клиент предоставляет заказ на товар и идентификатор
своей учетной записи (Id) для оплаты покупки.
2. Система получает информацию об учетной записи
клиента, включающую данные о кредитной карте клиента.
3. Система проверяет кредитную карту клиента на наличие
денег, достаточных для оплаты покупки. Если это
подтверждается, то создается номер авторизации покупки
с использованием кредитной карты (credit card purchase
authorization number).
4. Система создает заказ на доставку, который содержит
данные заказа, идентификатор клиента и номер
авторизации покупки с использованием кредитной карты.
5. Система подтверждает одобрение покупки и показывает
информацию о данном заказе клиенту.
6. Система отправляет подтверждение клиенту по
электронной почте.
Альтернативная последовательность
событий
• Шаг 2: Если клиент не имеет учетной записи, то
система предлагает клиенту предоставить
информацию для создания новой учетной записи.
– Клиент может или ввести информацию учетной записи
и прервать обработку заказа.
• Шаг 3: Если авторизация кредитной карточки
клиента завершилась неудачей (например,
неверная информация по карте, или недостаточно
денег на счете карты), то система предлагает
клиенту ввести номер другой кредитной карты.
– Клиент может или ввести другой номер карты и
прервать обработку заказа.
2. Определение объектов, требуемых для
реализации варианта использования
• Как и ранее, объекты, требуемые для реализации данного ВИ можно
выявить в результате тщательного чтения спецификации ВИ.
• При наличии актера, который является клиентом, здесь потребуются
следующие объекты:
1. объект взаимодействия клиентом («Взаимодействие с Клиентом»,
Customer Interaction).
2. 4 сервисных объекта:
–
–
–
–
3.
сервис учетной записи клиента (Customer Account Service),
сервис кредитной карты (Credit Card Service),
сервис доставки заказа (Delivery Order Service),
сервис электронной почты (Email Service).
координирующий объект (coordinator object) - координатор
клиента «Customer Coordinator» координирует взаимодействия
между
–
–
объектом «Взаимодействие с Клиентом» («Customer Interaction»)
и четырьмя сервисными объектами.
3. Определение последовательности
обмена сообщениями
• Последовательность обмена сообщениями между объектами
показана на рис.
• Она отражает взаимодействия между актером и системой, которое
описано в варианте использования.
Диаграмма последовательности
• Для ВИ «Make Order Request» также м.б. разработана
ДП: основная последовательность.
4. Определение альтернативной
последовательности ВИ
• Альтернативные сценарии
– Клиент не имеет учетной записи (account), в этом случае
будет создаваться новая учетная запись (new account)
– Отказано в авторизации кредитной карты, в этом случае
клиент получает возможность выбора другой кредитной
карты.
• Анализируется оба альтернативных вариантов.
• Альтернативный с новой учетной записью показан на
следующем слайде.
– Данный сценарий является вариантом основного сценария
на шаге M4A.
– Альтернативным ответом на запрос учетной записи на шаге
M3 является M4A [no account]: «Account does not exist».
– M4A это условное сообщение, которое посылается только в
том случае, если условии [no account] будет истинным.
•
Для данного альтернативного сценария последовательностью событий является от
M4A до M4A.8, которые описываются следующим образом:
•
M4A: Сервис учетных записей клиента (Customer Account Service) вернул Customer
Coordinator сообщение, о том, что клиент не имеет учетной записи.
•
M4A.1, M4A.2: объект «Customer Coordinator» отправляет объекту «Customer
Interaction» запрос на создание новой учетной записи для клиента.
•
M4A.3, M4A.4: клиент передает информацию учетной записи для объекта
«Customer Interaction», который пересылает данное сообщение объекту «Customer
Coordinator».
•
M4A.5: объект «Customer Coordinator» отправляет запрос к «Customer Account
Service» на создание новой учетной записи (new account).
•
M4A.6, M4A.7, M4A.8: сервис «Customer Account Service» подтверждает создание
новой учетной записи, в виде сообщения, которое возаращается клиенту через
объект «Customer Coordinator».
Диаграмма последовательности для
альтернативного сценария
• Ниже показана ДП для ВИ «Make Order Request»:
альтернативная последовательность для случая «Create
New Account».
Диаграмма коммуникации
• На рис. показана ДК для ВИ «Make Order Request»:
альтернативная последовательность для ситуации «Отказ
подтвердить кредитную карту» (Credit Card Denied).
Обобщенная ДК для ВИ «Make Order
Request»
• На рис. показана обобщенная ДК для ВИ «Make Order
Request» для основного и альтернативного потока событий.
• Те же самые сценарии ВИ «Make Order Request» показаны на
диаграмме последовательности (рис. 9.10).
• Данная ДП показывает две альтернативные последовательности:
– создания описания клиента в системе (account creation);
– подтверждение кредитной карты.
• Первый alt сегмент показывает две альтернативы [account exists] и
[no account].
• Второй alt сегмент также показывает две альтернативы [approved] и
[denied].
• В каждом случае пунктирная линия является разделителем между
альтернативами.
• На диаграмме последовательности нумерация сообщений является
не обязательной.
• В данном случае она приведена для показа соответствия с
диаграммой коммуникации.
Обобщенная ДП для ВИ «Make Order
Request»
• На рис. показана обобщенная ДП для ВИ «Make Order Request» для
основного и альтернативного потока событий.