Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 61
Текст из файла (страница 61)
Например, в постановке задачи о банкомате говорится о необходимости получения данных о транзакции от пользователя, но не указывается, какие конкретно параметры нужно у него спрашивать и в какой последовательности. Старайтесь не углубляться в подобные тонкости на этапе анализа. 264 Глава 13 ° Анализ приложения Банкомат просит пользователя вставить кредитную карту. Пользователь вставляет кредитную карту.
Банкомат принимает карту и считывает ее серийный номер. Банкомат запрашивает пароль. Пользователь вводит «1234». Банкомат проверяет пароль, связываясь с консорциумом и банком. Банкомат выводит меню действий над счетами и команд. Инициация сеанса Пользователь выбирает команду завершения сеанса. Банкомат печатает квитанцию, возвращает карту и просит пользователя взять ее иэ банкомата. Пользователь берет квитанцию и карту. Банкомат просит пользователя вставить кредитную карту.
Банкомат выводит меню счетов и команд. Пользователь выбирает запрос счета. Банкомат связывается с консорциумом и банком, которые предостав- ляют данные. Банкомат выводит данные о счете. Банкомат выводит меню счетов и команд. Запрос счета Банкомат выводит меню счетов и команд. Пользователь выбирает снятие денег со счета. Банкомат запрашивает снимаемую сумму.
Пользователь вводит $100. Банкомат проверяет сумму на превышение лимита выдачи наличных денег Банкомат связывается с консорциумом и банком для проверки нали- чия достаточной суммы на счете. Банкомат выдает наличные деньги и просит пользователя забрать их. Пользователь берет наличные деныи. Банкомат выводит меню счетов и команд. Обработка транзакции Банкомат запрашивает данные о счете, связываясь с консорциумом. Консорциум принимает запрос и направляет его в соответствующий банк. Банк принимает запрос и выдает требуемую информацию.
Банк отправляет информацию е консорциум. Консорциум направляет информацию банкомату. Передача данных Рис. 13.2. Типовые сценарии для банкомата Для большинства приложений порядок ввода выходных данных не имеет особой важности и может быть отложен до этапа проектирования. Подготовьте сценарии для типовых ситуаций — взаимодействий без необычных входных параметров и ошибочных ситуаций. Событием является обмен информацией между объектом системы и внешним агентом (пользователем, датчиком или другой задачей). Параметром события является передаваемая информация.
Например, параметром события «введен пароль» является сам введенный пароль. События без параметров тоже имеют значение и достаточно распространены. Само осуществление события является информацией. Для каждого события необходимо указать вызвавшее его лицо (систему, пользователя или иного внешнего агента) и параметры события. Пример с банкоматом.
На рис. 13.2 приведены типовые сценарии для каждого из вариантов использования. 13.1. Модель взаимодействия приложения 265 13.1.6. Нетипичные сценарии и исключительные ситуации После разработки типовых сценариев необходимо рассмотреть особые ситуации, такие как отсутствие ввеленных значений, ввод минимального и максимального значений, ввод одинаковых значений.
Затем нужно рассмотреть ошибочные ситуации, включая ввод неправильных значений и отсутствие отклика. Для многих интерактивных приложений обработка ошибок является наиболее сложной частью процесса разработки. Необходимо предоставлять пользователю возможность отменить операцию или откатиться к четко определенной начальной точке каждого этапа. Наконец, нужно рассмотреть дополнительные взаимодействия, которые могут пересекаться с базовыми (такие как обрашение к справочной системе или запрос сведений о состоянии).
Пример с банкоматом. Рассмотрим некоторые нетипичные сценарии и исключительные ситуации. Мы могли бы подготовить сценарии для каждого из них, но не хотим пока углубляться в детали (см. упражнения в конце этой главы). ° Банкомат не может прочитать карту. ° Срок действия карты истек. ° Тайм-аут при ожидании банкоматом ответа клиента. ° Сумма введена неверно.
° В банкомате кончились наличные или бумага. ° Линии связи не работают. ° Транзакция отклонена из-за подозрительной схемы использования карты. Дополнительные сценарии описывают работу административных частей системы банкомата: авторизацию новых карт, добавление банков к консорциуму, получение журналов транзакций. Эти аспекты мы раскрывать не будем. 13.1.7. Выделение внешних событий Проанализируйте все разработанные сценарии и выделите все внешние события: ввод данных, принятие решений, прерывания и взаимодействия с другими пользователями и внешними устройствами. Событие может вызывать действия целевого объекта. Этапы внутренних вычислений не являются событиями, за исключением расчетов, в ходе которых осушествляется взаимодействие с внешним миром, При помоши сценариев вы можете отыскать типовые события, но не забудьте и про нетипичные события и ошибочные ситуации.
Передача информации объекту является событием. Например, «введен пароль» — это сообщение, переданное от внешнего агента Пег (Пользователь) объекту приложения А ТМ (Банкомат). Некоторые потоки информации присутствуют в модели неявным образом. Многие события характеризуются определенными параметрами. Сгруппируйте под одинаковым названием события, оказываюшие олинаковое влияние на поток управления, даже если значения их параметров отличаются. Например, «введен пароль» — это событие, параметром которого является 266 Глава 13 ° Анализ приложения значение пароля.
Выбор значения пароля не влияет на поток управления, поэтому события с разными паролями являются экземплярами одного и того же типа событий. Аналогичным образом, «выдача наличных» также является событием независимо от суммы (параметра). Экземпляры событий, значения которых влияют на поток управления, должны быть отнесены к разным типам событий. «Правильный счет», «неверный счет» и «неверный пароль» — разные события, которые не следует группировать под названием «состояние карты». Вы должны следить за ситуациями, когда различия количественных значений достаточно существенны для того, чтобы события можно было считать разными. Например, нажатие любой цифровой клавиши на клавиатуре можно считать событием, не зависящим от конкретной цифры, тогда как нажатие клавиши «ввод» можно рассматривать отдельно, так как приложение будет обрабатывать его не так, как нажатие на цифровые клавиши. Различие событий зависит от приложения.
Подготовьте диаграмму последовательности для каждого сценария. Диаграмма последовательности показывает участников взаимодействия и последовательность сообщений, которыми они обмениваются. Каждому участнику выделяется свой столбец. Диаграмма показывает отправителя и получателя каждого сообщения. Если в объекте участвует несколько объектов одного и того же класса, им следует присвоить разные номера. Изучив один столбец таблицы, вы можете определить события, непосредственно влияющие на конкретный объект.
После этого вы можете сгруппировать события, отправляемые и принимаемые каждым классом. Пример с банкоматом. На рис. 13.3 показана диаграмма последовательности для сценария варианта использования ргосезз ггапзасйоп (обработка транзакции), На рис. 13.4 сгруппированы события. Стрелки указывают, какой объект является отправителем, а какой получателем (для каждого сообщения). Параметры событий на рис.
13А не показаны. Рис. 13.3. Диаграмма последовательности для сценария «обработка транзакции» 13.1. Модель взаимодействия приложения 267 приостановить, продолжить Пользователь Банкомат вывести основное меню, сообщение о невоз- можности считывания карты, сообщение об отмене, запрос пароля, запрос суммы, вынимание карты, сообщение об ошибке, выдача наличных, запрос изъятия карты, сообщение о проблемах со счетом, сообщение о неправильном коде банка, вывод меню транзакции обработка транзакции, ~ проверка счета, проверка средств проверка карты, проверка средств, обработка банковской транзакции Консорциум Банк банковская транзакция проведена успешно, подтверждение наличия средств, банковская транзакция не удалась, проверка банковского счета проведена, неправильный банковский счет, неправильный пароль Диаграммы последовательности описывают диалог и взаимодействие действующих лиц, но на них нельзя отразить имеющиеся альтернативы и принятые решения.
Вам придется рисовать отдельную диаграмму для основного потока взаимодействия и отдельные диаграммы для каждой ошибочной ситуации и каждой точки принятия решения. Диаграммы деятельности позволяют объединить все это поведение благодаря документированию ветвлений и слияний потока управления, Диаграммы деятельности можно использовать для документирования бизнес-логики на этапе анализа, однако не стоит оправдывать ими ранний переход к реализации. Пример с банкоматом. На рис. 13.5 показано, что помещение клиентом карты в банкомат может вызвать множество различных последствий.
Некоторые варианты отклика указывают на наличие проблем с картой или счетом (банкомат не возвращает карту). Только успешное прохождение проверки разрешает продолжать работу с банкоматом. На следующем этапе нужно упорядочить варианты использования при помощи отношений включения, расширения и обобщения (см. главу 8). Это особенно полезно для больших и сложных систем. Как и с моделями классов и состояний, мы вставить карту, ввести пароль, выбрать депонирование, выбрать снятие денег, трансфер средств, запросить счет, ввести сумму, взять деньги, взять карту, отменить, Рис.
13.4. События для примера с банкоматом 13.1.8. Подготовка диаграмм деятельности для сложных вариантов использования 13.1.9. Структурирование действующих лиц и вариантов использования транзакция прошла успешно, транзакция не удалась, проверка счета проведена, неправильный счет, неправильный пароль, неправиль- ный код банка, подтверждение наличия средств 268 Глава 13 ° Анализ приложения откладываем структурирование до тех пор, пока ие будут выписаны все базовые варианты использования. Если выполнить структурирование слишком рано, существует опасность искажения приложения из-за фиксирования подсозиательных соображений в структуре вариантов использования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
