Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 60
Текст из файла (страница 60)
Для сложных и неочевидных вариантов использования нужно построить диаграммы деятельности. После того как вы полностью разберетесь в вариантах использования, их можно упорядочить при помощи отношений. Наконец, необходимо провести проверку модели взаимодействия по модели классов предметной области: несогласованности между ними быть не должно. Модель взаимодействия для приложения строится в несколько этапов.
1. Определить границу системы (раздел 13.1.1). 2. Выделить действуюшие лица (раздел 13.1.2). 3. Выделить варианты использования (раздел 13.1.3). 260 Глава 13 ° Анализ приложения 4. Выделить начальные и конечные события (раздел 13.1А). 5. Подготовить типовые сценарии (раздел 13.1.5). 6. Добавить сценарии, описываюшие вариации и исключительные ситуации (раздел 13.1.6). 7. Выделить внешние события (раздел 13.1.7).
8. Построить диаграммы деятельности для сложных вариантов использования (раздел 13.1.8). 9. Структурировать действуюшие лица и варианты использования (раздел 13.1.9). 10. Выполнить проверку по модели классов предметной области (раздел 13.1.10). 13.1.1. Определение границы системы Для описания функциональности нужно точно знать область приложения, то есть границы системы. Вы должны решить, что будет входить в вашу систему, а что— нет (последнее даже более важно).
Если граница системы очерчена корректно, во всех взаимодействиях вы сможете рассматривать систему как черный яшик— единый объект, внутренние особенности которого скрыты от внешнего взгляда и могут быть реализованы по-разному. В процессе анализа вы должны определить назначение системы и ее вид с точки зрения действующих лиц. В процессе проектирования вы сможете менять внутреннюю реализацию системы при условии сохранения внешнего поведения. Обычно людей не следует рассматривать как часть системы, если только вы не занимаетесь моделированием организации (напрнмер, частной компании или правительственного учреждения).
Люди — это действующие лица, которые должны взаимодействовать с системой, но их действия не управляются ею. Напротив, вы как разработчик системы должны учитывать, что люди могут ошибаться. Пример с банкоматом. В исходной постановке задачи нз главы 11 говорится, что вы должны «разработать программное обеспечение компьютеризованной банковской сети, включающей кассиров и банкоматы». На данном этапе важно обеспечить «бесшовное» согласование транзакций, проводимых на кассах и с помощью банкоматов.
С точки зрения пользователя любой из этих методов должен давать один и тот же конечный результат. Однако коммерческая практика диктует, что приложение для банкоматов сушествует отдельно от приложения для кассиров, потому что первое работает с несколькими банками, тогда как второе используется внутри одного банка. Оба приложения основаны на обшей модели предметной области, но каждое из них имеет свою собственную модель приложения.
В этой главе мы будем заниматься только поведением банкомата, а о кассирах пока забудем. 13.1.2. Идентификация действующих лиц После определения границ системы вы должны идентифицировать внешние объекты, непосредственно взаимодействуюшие с системой. Это и будут действуюшие лица. К пх числу принадлежат люди, внешние устройства и другие программные системы.
Самым важным качеством действуюших лнц является то, что они 13.1. Модель взаимодействия приложения 261 не контролируются приложением, а их поведение должно считаться непредсказуемым. Несмотря на то что может существовать какая-то ожидаемая последовательность действий действуютцего лица, приложение должно быть достаточно устойчивым, чтобы выдерживать нарушение этой последовательности.
В процессе поиска действующих лиц нас интересуют не индивидуальные сущности, а сущности с архетипичным поведением. Каждое действующее лицо представляет идеализированного пользователя, который задействует какое-либо подмножество функциональности системы. Изучите каждый внешний объект и выясните, не характеризуется ли он существенно различными видами поведения. Действующее лицо — это один вариант поведения по отношению к системе, а один внешний объект может соответствовать нескольким действующим лицам. С другой стороны, разные типы внешних объектов могут описываться одним действующим лицом. Пример с банкоматом.
Один человек может одновременно быть кассиром и клиентом одного и того же банка. Это интересное совпадение, которое, однако, чаше всего не является важным. По отношению к банку человек всегда выступает либо в одной, либо в другой роли. Для приложения банкомата действующими лицами будут Сизготег(Клиент), Вап)г (Банк) и Сопгогггит (Консорциум).
13.1.3. Идентификация вариантов использования Для каждого действующего лица необходимо перечислить разные способы использования системы. Каждый из этих способов называется вариантом использования (цзе саве). Варианты использования разбивают функциональность системы на несколько дискретных единиц. Любое поведение системы должно принадлежать какому-либо варианту использования. Иногда могут возникнуть проблемы с отнесением какого-либо пограничного поведения к тому или иному варианту использования.
При разбиении всегда следует помнить о том, что всегда существуют пограничные варианты. В этом случае решение можно принять произвольно. Каждый вариант использования должен представлять собой некий сервис (услугу), предоставляемый системой, то есть нечто ценное для действующего лица. Все варианты использования следует рассматривать на одном уровне детализации. Например, если один из вариантов использования для банка называется запросить ссуду, то другой вариант не должен называться снять пгьтичпые с депозитного счета через банкомат. Второе название слишком детализированное по сравнению с первым.
Лучше назвать этот вариант просто снять деньги. Постарайтесь сосредоточиться на основной цели варианта использования н не принимать решений по его реализации. На этом этапе вы можете нарисовать предварительную диаграмму вариантов использования. На ней следует показать действующие лица и варианты использования, соединив их между собой. Обычно вариант использования можно соединить с действующим лицом, которое его инициирует, но, вообще говоря, в нем могут участвовать и другие действующие лица. Не беспокойтесь о том, что вы можете пропустить их.
В процессе проработки вариантов использования это станет очевидно. Кроме того, для каждого варианта использования полезно сформулировать его краткое описание в одно-два предложения. 262 Глава 13 ° Анализ приложения Пример с банкоматом. На рис. 13.1 показаны варианты использования, краткое описание которых приведено в списке ниже. ° 1тйасе зезх(оп (Инициализация сеанса). АТМ определяет личность пользо- вателя и предлагает ему список счетов и действий. ° Две~у ассоинг (Опрос счета).
Система предоставляет общие сведения о счете, такие как текущий баланс, дату последней транзакции, дату отправки последнего отчета по почте. ° Ргосехт гганзасг(ов (Обработка транзакции). Система банкомата выполняет действие, влияющее на баланс счета, такое как вклад, снятие и перевод. Банкомат гарантирует, что все завершенные транзакции в конечном итоге записываются в базу данных банка.
° тганзвпг вага (Передача данных). Банкомат использует возможности консорциума для взаимодействия с компьютерами соответствующего банка. Банк сорциум Рис. 13.1. Диаграмма вариантов использования для банкомата 13.1А. Идентификация начальных и конечных событий Варианты использования разбивают функциональность системы на дискретные части н показывают действующие лица, использующие каждую из этих частей. Однако поведение системы демонстрируется в них недостаточно четко.
Для понимания поведения необходимо знать последовательности выполнения, соответствующие каждому из вариантов использования. Начинать их анализ следует с поиска событий, инициирующих каждый из вариантов использования. Определите, какое лицо инициирует вариант использования, и определите событие, которое оно для этого передает системе. Во многих случаях начальным событием является запрос некоторой услуги, предоставляемой системой. В других случаях начальным событием является происшествие, запускающее цепочку действий.
Дайте этому событию осмысленное название, но пока не пытайтесь определить полный список его параметров. 13,1. Модель взаимодействия приложения 263 Кроме того, следует определить конечное событие или группу событий, а также общие рамки событий, которые должны быть включены в каждый из вариантов использования. Например, вариант использования запрос ссуды может продолжаться до тех пор, пока просьба не будет подана, пока ссуда не будет выдана или отклонена или пока ссуда не будет погашена и закрыта.
Любой из этих вариантов вполне приемлем. Разработчик молели должен определить границы варианта использования, установив его конечное событие. Пример е банкоматом. Здесь мы приводим начальное и конечное событие для каждого варианта использования. ° 1п1г1асе зеЫоп (Инициализация сеанса). Начальным событием является помещение клиентом банковской карты в банкомат. Конечных событий может быть два: либо система оставляет банковскую карту себе, либо возвращает ее обратно клиенту. ° Яцеку ассоииг (Опрос счета). Начальное событие: клиент запрашивает данные о состоянии счета. Конечное событие: выдача необходимых сведений клиенту. ° Ргосея ггатасг|оп (Обработка транзакции).
Начальное событие: клиент инициирует транзакцию. Конечных событий может быть два: завершение или откат транзакции. ° Тгапзлпг Нага (Передача данных). Начальным событием может быть запрос клиентом данных о состоянии счета. Кроме того, передача данных может быть инициирована после устранения неполадок в сети или перебоев с питанием. Конечное событие: успешная передача данных. 13.1.5.
Подготовка типовых сценариев Для каждого варианта использования нужно подготовить один или несколько типичных сценариев, чтобы почувствовать ожидаемое поведение системы. Эти сценарии описывают основные взаимодействия, форматы внешних отображаемых данных, а также обмен информацией. Сценарием (зсепано) называется последовательность событий на множестве взаимодействующих обьектов. Анализ следует осуществлять в терминах примеров взаимодействия, а не расписывать наиболее общие варианты.
Таким образом, вы будете уверены, что не пропустите важные этапы и что общая последовательность взаимодействия получится корректной. Для большинства задач логическая корректность зависит от взаимной последовательности взаимодействий, а не от конкретных временных промежутков между ними. (Системы реального времени предьявляют и временные требования к взаимодействиям, но мы в своей книге не рассматриваем такие системы.) Иногда описание задачи полностью задает последовательность взаимодействия, но в большинстве случаев вам придется прилумывать ее (или, по крайней мере, конкретизировать).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
