Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 38
Текст из файла (страница 38)
Каждое действующее лицо должно принимать участие по крайней мере в одном варианте использования. Вариант использования может иметь несколько действующих лиц, действующее лицо может участвовать в нескольких вариантах использования. ° Помните о том, что варианты использования не являются формальным описанием системы. Не стоит добиваться формальности описания вариантов использования. Они были придуманы для того, чтобы идентифицировать и упорядочивать функциональность системы с точки зрения пользователя.
Варианты использования на первом зтапе вполне могут быть определены недостаточно четко. Подробности добавляются позже, когда варианты использования расширяются и реализуются. ° Варианты использования можно структурировать. Для многих приложений вполне достаточно отдельных вариантов использования. В больших системах можно конструировать варианты использования из отдельных фрагментов, используя отношения между ними (см. главу 8). 7.2. Модели последовательности Модель последовательности представляет собой углубленное рассмотрение ситуаций, описываемых вариантами использования.
Такие модели бывают двух типов: сценарии и диаграммы последовательности. Последние обладают более четкой структурой. 7.2.1. Сценарии Сценарий (зсепапо) — зто последовательность событий, осуществляющихся в процессе одного конкретного выполнения системы, например в соответствии с каким-либо вариантом использования.
Сценарий может иметь различную область охвата: он может описывать все события системы или только те, которые влияют на конкретные объекты или порождаются нми. Сценарий можно рассматривать как журнал выполнения фактической системы илн как мысленный эксперимент, в котором участвует предлагаемая система. Сценарий может быть представлен в виде текста (рис. 7А). В нашем примере Джон Доу входит в сетевую брокерскую систему, размещает заказ на приобретение акций Сепега( Е)есгг1с, после чего отключается.
Через некоторое время после выполнения заказа фондовая биржа сообщает результаты сделки брокерской системе. Джон Доу увидит результаты выполнения своего заказа при следующем входе в систему, но наш сценарий зто не описывает. 168 Глава 7 ° гчоделироаание взаимодействий Джон Доу входит в систему. Система устанавливает безопасные соединения. Система выводит информацию ло лортфолио. Джон Доу вводит заказ на покупку 100 акций ОЕ ло рыночной цене. Система проверяет наличие необходимых средств для совершения сделки. Система выводит запрос подтверждения и предполагаемую стоимость.
Джон Доу подтверждает сделку. Система размещает заказ на фондовой бирже. Система выводит номер транзакции. Джон Доу выходит из системы. Система устанавливает незащищенное соединение. Система выводит сообщение о завершении сеанса. Фондовая биржа сообщает о результатах торгов. Рис. 7.4. Сценарий для он-лайноаой брокерской сделки Наш пример отражает взаимодействие на самом высоком уровне. Такой этап, как Джон Доу входит в Систему, может потребовать обмена несколькими сообщениями между Джоном Доу и Системой. Однако суть этапа сводится к тому, что Джон Доу запрашивает систему о входе и предоставляет необходимые идентификационные данные.
Детали реализации можно показать отдельно. На ранних стадиях разработки вы должны описывать сценарии в терминах высоких уровней. На более поздних стадиях можно показывать отдельные сообщения. Определение порядка обмена сообщений относится к проектированию.
Сценарий содержит информацию о сообщениях, которыми обмениваются объекты, а также о деятельности, выполняемой объектами. Каждое сообщение передает информацию от одного объекта другому. Например, Джоя Доу входит в Систему передает сообщение от Джона Доу брокерской системе. Написание сценария начинается с идентификации объектов, обменивающихся сообщениями.
После этого определяются отправитель и получатель каждого сообщения, а также последовательность сообщений. Наконец, можно добавить в сценарий деятельность, соответствующую внутренним вычислениям. Это делается уже на этапе кодирования. 7.2.2. Диаграммы последовательности Текстовые сценарии удобно писать, но они не позволяют наглядно показать отправителя и получателя каждого сообщения, особенно если количество объектов превышает два. Диаграмма последовательности показывает участников взаимодействия и последовательность сообщений, которыми они обмениваются.
Она описывает взаимодействие системы с действующими лицами в процессе полного или частичного выполнения варианта использования. На рис. 7.5 показана диаграмма последовательности, соответствующая описанному выше сценарию сделки на бирже. Каждое действующее лицо, как и система, обозначается вертикальной линией, которая называется линией жизни, а каждое сообщение — горизонтальной стрелкой, направленной от отправителя 7.2.
!Яоделн последовательности 169 к получателю. Время направлено сверху вниз, однако масштаб на диаграмме не соблюдается. Диаграмма показывает только последовательность сообщений, а не точный их порядок во времени. В системах реального времени можно накладывать ограничения на последовательности событий, однако это требует дополнительных обозначений. Обратите внимание, что на диаграммах последовательности могут изображаться и параллельные сигналы: брокерская система отправляет сообщения клиенту и фондовой бирже параллельно. Кроме того, сигналы между участниками взаимодействия не обязаны чередоваться: брокерская система отправляет защищенное сообщение, за которым следует отображение портфеля ценньгх бумаг. сопйпп рогславе сыр!ау оп1ег пьтЬег Ргасе огаег 1овоог !пвесоге согпгпоп!сеьоп !екеси1е огеег1 агар!ау 9ооа Ьуе герог1 твоав о1 !гаев Рнс.
7.5. Диаграмма последовательности для он-лайноаой брокерской сделки Описание поведения каждого варианта использования требует по крайней мере одной диаграммы последовательности. Каждая диаграмма последовательности показывает конкретную последовательность поведения варианта использования. Лучше всего изображать на диаграмме определенную часть варианта использования и не стремиться к максимальной общности. На диаграмме последовательности можно показывать условия, но обычно модель получается яснее, если для каждого существенного потока управления строится своя диаграмма последовательности. Диаграммы последовательности могут описывать крупномасштабные взаимодействия, такие как сеанс работы с сетевой брокерской системой, но достаточно часто взаимодействия такого рода содержат независимые задачи, которые могут комбинироваться разными способамн.
Вместо того чтобы повторять одно и то же для разных комбинаций, вы можете нарисовать отдельную диаграмму последовательности для каждой задачи. На рис. 7.6 и 7.7 показан заказ на приобретение пакета акций и запрос на котировку пакета. Эти задачи, вместе со многими другими, являются составляющими сеанса работы с сетевой брокерской системой как целого. Обязательно нужно строить диаграмму последовательности для каждой исключительной ситуации, возможной для данного варианта использования.
В качестве примера на рис. 7.8 изображена ситуация, в которой у клиента оказалось 170 Глава 7 ° Моделирование взаимодействий недостаточно средств для размещения заказа. В этом случае клиент отменяет заказ. Однако ои мог бы изменить количество приобретаемых акций, и тогда заказ был бы принят. гоеп Рис. 7.6. Диаграмма последовательности совершения покупки акций Рис. 7.7. Диаграмма последовательности запроса котировок Рис.
7.8. Диаграмма последовательности неудачной покупки В большинстве систем количество возможных сценариев бесконечно, поэтому показать их все иа диаграммах последовательности невозможно. Однако нужно стараться проработать все варианты использования и описать основные виды поведения при помощи диаграмм последовательности.
Например, в биржевой системе покупки, продажи и запросы котировок могут чередоваться между собой 7.3. Модели деятельности 171 произвольным образом. Необязательно показывать все варианты деятельности, достаточно рассмотреть один из основных вариантов. 7.2.3. Руководство к диаграммам последовательности Модель последовательности прорабатывает и детализирует неформальное описание системы, заданное вариантами использования.
Модели последовательности бывают двух видов. Сценарии представляют собой текстовое описание последовательности событий. Диаграммы последовательности тоже описывают последовательности событий, но в графической форме, что позволяет наглядно показать участников взаимодействия. При построении моделей последовательности можно руководствоваться следующими соображениями: ° Для каждого варианта использования нужно написать по крайней мере один сценарий. Этапами сценария должны быть логические команды, а не отдельные щелчки мыши и нажатия на клавиши.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
