2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 50
Текст из файла (страница 50)
Этим определяется субъект. Идентифицировать действующие лица, окружающие систему, рассмотрев при этом, какие группы требуют помощисо стороны системы в выполнении своих задач, какие необходимы для обеспечения функционирования системы, какиевзаимодействуют с внешним оборудованием или другимипрограммными системами и какие осуществляют вторичныефункции по администрированию и поддержке. Организовать схожие действующие лица в иерархии обобщения–специализации.
Там, где это требуется для лучшего понимания модели, представить стереотип для каждого из действующих лиц.Наполните диаграмму вариантов использования этими действующими лицами и опишите пути взаимодействия каждого из нихс вариантами использования системы.В примере на рис. 18.2 показан контекст системы проверки кредитных карт (Credit Card Validation System), с описанием действующихлиц, окружающих ее. Вы видите клиентов (Customers), которыеподразделяются на две группы: Individual customer (Частный клиент)и Corporate customer (Корпоративный клиент). Эти действующие лицапредставляют роли, которые играют люди при взаимодействииРис. 18.2.
Моделирование контекста системыТипичные приемы моделирования257с системой. В данном контексте показаны также действующие лица,представляющие другие учреждения, – такие как Retail Institution(Предприятие розничной торговли), с которым Customer взаимодействует посредством карточной транзакции, приобретая товарили услугу, и Sponsoring financial Institution (Институт финансовогоспонсирования) – депозитный центр для карточных счетов.
В действительности последние два, скорее всего, будут представлены программными системами.ПодсистемыТе же приемы применимы для моделирования контекста подобсуждают- систем. То, что является системой на одном уровне абстракции, часся в главе 32. то предстает составляющей частью более крупной системы на другом, более высоком. Поэтому моделирование контекста подсистемполезно, когда вы разрабатываете систему с «вложениями».Моделирование требований к системеТребование определяет функцию, свойство или поведение системы. Формулируя требования к системе, вы составляете контрактмежду ней и теми сущностями, которые находятся вне ее.
Этот контракт декларирует то, что система должна делать. Большей частьювас не заботит то, как она это будет делать – важно, чтобы она отвечала заявленным требованиям. Хорошая система выполняет требования точно, предсказуемо и надежно. Приступая к построениюсистемы, важно начать с соглашений о том, что она должна делать,хотя, скорее всего, в процессе ее реализации вы будете не раз уточнять эти требования. Аналогичным образом, когда вы вводите систему в эксплуатацию, знание ее поведения весьма существенно дляее правильного использования.ПримечанияТребования могут быть выражены в различных формах – от неможноструктурированного текста до выражений формального языка.
Больприменятьшинство функциональных требований к системе, если не все они,могут быть выражены в виде вариантов использования, а потомудля фордля управления этими требованиями важны диаграммы вариантовмулировкитребований, использования UML.Чтобы смоделировать требования к системе, необходимо:как показанов главе 6. Установить контекст системы, идентифицируя действующиелица, окружающие ее. Рассмотреть поведение системы, которого от нее ожидает илитребует каждое действующее лицо. Обобщить это поведение в виде вариантов использования. Выделить общее поведение в новые варианты использования, на которые ссылаются другие варианты; выделить разновидности поведения в новые варианты использования,расширяющие основные потоки.258Диаграммы вариантов использования Смоделировать эти варианты использования, действующиелица и их связи на диаграмме вариантов использования.
Снабдить варианты использования примечаниями или ограничениями, которые задают нефункциональные требования;возможно, некоторые из них вы присоедините ко всей системе.Моделированиединамикидля распределениянагрузкии реконфигурации сетиобсуждается в главе 24.Рис. 18.3 дополняет диаграмму вариантов использования, показанную на предыдущем рисунке. Здесь скрыты связи между действующими лицами и вариантами использования, но зато вводятсядополнительные варианты использования, которые не видимыобычному пользователю, хотя и представляют важные аспекты поведения системы.
Диаграмма полезна тем, что может послужить дляконечных пользователей, экспертов в предметной области и разработчиков общей отправной точкой в процессе визуализации, специфицирования, конструирования и документирования их совместных решений, касающихся функциональных требований к системе.Например, Detect card fraud (Обнаружение мошенничеств) – это поведение, которое важно как для предприятий розничной торговли,так и для институтов финансового спонсирования. Report on accountstatus (Отчет о состоянии счета) – еще одно поведение, требуемоеот системы различными учреждениями в ее контексте.Рис. 18.3. Моделирование требований к системеТребование, которое моделируется вариантом использованияManage network outage (Управление сетевыми потоками), несколько отлично от всех остальных, поскольку описывает вторичноеТипичные приемы моделирования259поведение системы, необходимое для обеспечения ее надежной непрерывной работы.Определив структуру варианта использования, вы должны описать поведение каждого из них.
Обычно нужно составить одну илинесколько диаграмм последовательности для каждого основного сценария, затем – диаграммы последовательности для вариацийсценариев и, наконец, хотя бы одну диаграмму последовательности, иллюстрирующую каждый из возможных типов ошибок илиисключений. Обработка ошибок – часть варианта использования,Подсистемы поэтому она должна быть запланирована наряду с нормальным пообсуждают- ведением.Те же приемы применяются при моделировании подсистем.ся в главе 32.Прямое и обратное проектированиеДиаграммыобсуждаются в главе 7,вариантыиспользования –в главе 14.Большинство других диаграмм UML, включая диаграммы классов, компонентов, состояний, – явные кандидаты на прямое и обратное проектирование, потому что каждая из них имеет некий аналог в исполняемой системе. Диаграммы вариантов использованияв этом смысле стоят слегка особняком, потому что они скорее отражают, чем специфицируют реализацию системы, подсистемы иликласса.
Варианты использования описывают то, как ведет себя элемент, а не то, как он реализован, поэтому они не могут быть подвергнуты прямому и обратному проектированию.Прямое проектирование (forward engineering) – это процесстрансформации модели в код путем ее отображения на язык реализации. Диаграмма вариантов использования может быть подвергнута прямому проектированию с целью формирования тестовдля того элемента, который она описывает. Каждый вариант использования на такой диаграмме специфицирует поток событийс его вариациями, и все эти потоки описывают ожидаемое поведение элемента – то есть нечто такое, что подлежит тестированию. Хорошо структурированный вариант использования дажеспецифицирует предF и постусловия, которые могут применятьсяв целях определения начального состояния теста и критериев егоуспешности.
Для каждого варианта использования из диаграммывы можете создать сценарий тестирования (test case), который будет выполняться при выпуске каждой новой версии данного элемента, таким образом подтверждая, что он работает надлежащимобразом, прежде чем другие элементы смогут опираться на негов своей работе.Чтобы осуществить прямое проектирование диаграммы вариантов использования, необходимо:260Диаграммы вариантов использования Идентифицировать объекты, которые взаимодействуют с системой. Попытайтесь идентифицировать различные роли, которые может играть каждый внешний объект. Создать действующее лицо, представляющее каждую из отдельных взаимодействующих ролей.
Для каждого варианта использования на диаграмме идентифицировать основной и исключительный потоки событий. В зависимости от того, насколько тщательно вы собираетесьпроводить тестирование, сгенерировать соответствующийсценарий для каждого потока, используя предусловие потока как начальное состояние теста и постусловие – как критерий успешности. При необходимости сгенерировать тестовую инфраструктуру, которая будет представлять каждое из действующихлиц, взаимодействующих с вариантом использования. Действующие лица, вводящие информацию для элемента либопроизводящие над ним какиеFто действия, могут быть симулированы, или вместо них понадобится подставить некийэквивалент из реального мира.
Использовать инструментальные средства для запуска каждого из этих тестов всякий раз, когда вы реализуете элемент,к которому относится диаграмма вариантов использования.Обратное проектирование (reverse engineering) – процесс трансформации кода в модель посредством его отображения из определенного языка реализации. Автоматически выполнить обратноепроектирование диаграммы вариантов использования на данномэтапе не представляется возможным, потому что на пути от спецификации поведения элемента к его реализации происходит потеряинформации. Однако в ваших силах изучить существующую систему и распознать ее подразумеваемое поведение самостоятельно,с тем чтобы на этой основе оформить диаграмму вариантов использования.
В любом случае неплохо это делать каждый раз, когдавы имеете дело с недокументированным программным обеспечением. Диаграммы вариантов использования UML просто предоставляют вам стандарт и выразительный язык, чтобы можно былозафиксировать то, что вы при этом обнаружите.Чтобы осуществить обратное проектирование диаграммы вариантов использования, необходимо: Идентифицировать каждое действующее лицо, взаимодействующее с системой. Исследовать манеру взаимодействия каждого из них с системой, изменение ее состояния или состояния среды, реакциюна события.Советы и подсказки261 Проследить поток событий в исполняемой системе относительно каждого действующего лица, начав с основных потоков и во вторую очередь изучив альтернативные. Объединить в группы взаимосвязанные потоки, определяясоответствующие варианты использования.
Рассмотреть варианты моделирования с применением связей расширенияи моделирование похожих потоков с применением связейвключения. Отобразить эти варианты использования и действующиелица на диаграмме вариантов использования и установитьих связи.Советы и подсказкиКогда вы создаете диаграммы вариантов использования в UML,помните, что каждая такая диаграмма – это просто графический срезстатического представления вариантов использования системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
