Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование (1158625), страница 57
Текст из файла (страница 57)
Услож нение диаграмм возникает и на стадии анализа, и при проектирова нии. Всегда нужно стремиться создавать максимально простые диа граммы взаимодействия, однако иногда это невозможно. В этих случа ях надо попробовать методы, представленные в этой главе.13.2. Включения взаимодействий13.2.1. Параметры13.2.2. Шлюзы13.4. Что мы узналиРис. 13.1. План главы13.3. Продолжения300Глава 13. Дополнительные аспекты реализации прецедентов13.2. Включения взаимодействийОчень часто одна и та же последовательность сообщений многократновстречается в разных диаграммах последовательностей. Очевидно, чтоперерисовывать много раз один и тот же фрагмент взаимодействия –занятие утомительное и чреватое появлением ошибок.
Поэтому в этихслучаях применяются включения взаимодействий.Включения взаимодействий – это ссылки на другое взаимодействие.Включения взаимодействий – это ссылки на взаимодействие. Когдатакое включение помещается во взаимодействие, то в данной точкевключается поток взаимодействия, на который ссылается данное вклю чение взаимодействия.Давайте в качестве примера рассмотрим фрагмент простой системырегистрации курсов, которая обсуждалась в главе 12. Диаграммаклассов анализа для интересующей нас части системы представленана рис.
12.7 (стр. 276).Прежде чем актер Registrar (рис. 12.6) сможет работать с системой, ондолжен в нее войти. Это требование реализуется путем добавления надиаграмму (рис. 12.7) класса SecurityManager (менеджер безопасности),как показано на рис. 13.2.Рассмотрим прецедент LogOnRegistrar (вход регистратора в систему), по казанный на рис. 13.3.
Он будет включен во все прецеденты, в кото рых Registrar сначала должен войти в систему.Можно полагать, что фрагмент взаимодействия для входа Registrarв систему будет иметь место в начале многих диаграмм последователь ностей. Имеет смысл выделить это общее поведение в отдельную диа грамму последовательностей и затем ссылаться на нее в случае необхо SecurityManager11RegistrationManager10..*Coursecourses0..*registration0..*10..*StudentstudentsРис. 13.2. На диаграмму классов анализа добавлен класс SecurityManager30113.2. Включения взаимодействийПрецедент: LogOnRegistrarID: 4Краткое описание:Registrar входит в систему.Главные актеры:RegistrarВторостепенные актеры:Нет.Предусловия:1.
Registrar еще не вошел в систему.Основной поток:1. Прецедент начинается, когда Registrar выбирает «log on».2. Система спрашивает у Registrar имя пользователя и пароль.3. Registrar вводит имя пользователя и пароль.4. Система принимает имя пользователя и пароль как действительные.Постусловия:1.
Registrar вошел в систему.Альтернативные потоки:InvalidUserNameAndPasswordRegistrarAlreadyLoggedOnРис. 13.3. Спецификация прецедента LogOnRegistrarдимости. На рис. 13.4 показана диаграмма последовательностей LogOnRegistrar, содержащая многократно используемый фрагмент взаимо действия.На рис. 13.5 представлена другая диаграмма последовательностей, ChangeStudentAddress (изменить адрес студента), включающая взаимодейст вие LogOnRegistrar.Вся последовательность событий ChangeStudentAddress представленав табл.
13.1.sd LogOnRegistrar:RegistrarlogOn( userName, password ):SecurityManagerauthenticate( userName, password )Рис. 13.4. Диаграмма последовательностей, содержащая многократноиспользуемый фрагмент взаимодействия302Глава 13. Дополнительные аспекты реализации прецедентовsd ChangeStudentAddress:SecurityManager:Registrar:RegistrationManagertheStudent:Studentref LogOnRegistrarвключениевзаимодействияtheStudent = findStudent( name )setAddress( newAddress )Рис. 13.5. Диаграмма последовательностей с включением взаимодействияТаблица 13.1ДиаграммаИсходнаялиния жизниСообщениеЦелеваялиния жизниLogOnRegistrar:RegistrarlogOn(...):SecurityManagerLogOnRegistrar:SecurityManagerauthenticate(...):SecurityManagerChangeStudentAddress:RegistrarfindStudent(...):RegistrationManagerChangeStudentAddress:RegistrarsetAddresstheStudent:StudentПриведем несколько моментов, о которых необходимо помнить прииспользовании включений взаимодействия.• Взаимодействие, на которое ссылается включение, вставляется вовключающее взаимодействие в точке, где впервые появляется вклю чение взаимодействия.• По завершении включаемого взаимодействия необходимо бытьочень внимательным к тому, где оказывается фокус управления!Следующее сообщение, отправляемое во включающем взаимодей ствии, должно быть согласовано с положением фокуса.• Все линии жизни, участвующие во включении, должны присутст вовать и во включающем взаимодействии.• Чтобы обозначить область действия включения взаимодействия,оно отрисовывается поверх всех используемых им линий жизни.13.2.1.
ПараметрыВзаимодействия могут иметь параметры. Это обеспечивает возмож ность поставлять взаимодействию разные значения в каждом включе нии взаимодействия. Параметры могут быть заданы с помощью обыч ного синтаксиса операций, рассмотренного в разделе 7.5.3.30313.2. Включения взаимодействийsd FindStudent( name : String ) : Student:RegistrationManager:RegistrarfindStudent( name )sd FindCourse( name : String ) : Course:RegistrationManager:RegistrarfindCourse( name )Рис. 13.6.
Параметризованные взаимодействияПараметры дают возможность использовать конкретные значения вовзаимодействии.На рис. 13.6 показаны операции FindStudent(...) и FindCourse(...) – два па раметризованных взаимодействия.На рис. 13.7 показан пример использования параметризованных взаи модействий. Обратите внимание на то, как можно передавать во взаи sd RegisterJimForUMLCourse:Registrarrefref:RegistrationManagertheCourse:CoursetheStudent = FindStudent( "Jim" )theCourse = FindCourse( "UML" )register( theStudent )Рис. 13.7.
Передача конкретных значений в виде параметров304Глава 13. Дополнительные аспекты реализации прецедентовмодействия конкретные значения в виде параметров. Это обеспечиваетогромные возможности и гибкость!На рис. 13.7 можно увидеть, что два варианта употребления взаимо действий возвращают значения, присваиваемые временным перемен ным theStudent (студент) и theCourse (курс). Эти временные переменныесуществуют в области действия диаграммы последовательностей.13.2.2. ШлюзыШлюзы (gates) – это входы и выходы взаимодействий.Шлюзы – это входы и выходы взаимодействий.Шлюзы используются, когда взаимодействие необходимо иницииро вать линией жизни, которая не является частью взаимодействия. Вос пользуемся операциями FindStudent и FindCourse на рис.
13.6, чтобы про иллюстрировать применение шлюзов (рис. 13.8).Как видно из рисунка, шлюз – это точка на рамке диаграммы последо вательностей, соединяющая сообщение, находящееся вне рамки, с со общением внутри рамки. Сигнатуры обоих сообщений должны бытьодинаковыми.Рисунок 13.7 можно изменить, применив эти новые диаграммы после довательностей со шлюзами, как показано на рис. 13.9.Теперь у FindStudent и FindCourse есть явные входы и выходы. Эти взаи модействия даже стали еще более гибкими, чем раньше.
Рассмотримрис. 13.10, на котором показан другой возможный вариант примене ния взаимодействия FindCourse.sd FindStudent:RegistrationManagerfindStudent( name )шлюзыsd FindCourse:RegistrationManagerfindCourse( name )Рис. 13.8. Шлюзы30513.2. Включения взаимодействийsd RegisterJimForUMLCourse:RegistrationManager:RegistrartheCourse:CoursereftheStudent = findStudent( "Jim" )FindStudentшлюзreftheCourse = findCourse( "UML" )FindCourseregister( theStudent )Рис.
13.9. Диаграммы последовательностей с шлюзамиИ шлюзы, и параметры обеспечивают гибкость в многократном ис пользовании взаимодействий. Возникает вопрос: когда должны при меняться шлюзы, а когда – параметры?• Параметры используются, когда известны исходные и целевые ли нии жизни всех сообщений взаимодействия.• Шлюзы используются, когда некоторые сообщения приходят из заграниц рамки взаимодействия и заранее неизвестно, откуда они мо гут поступить.sd GetStudentsOnUMLCourse:Registrar:RegistrationManageruml:CoursegetRegisteredStudents( "UML" )uml = findCourse( "UML" )refFindCoursetheStudents = getStudents()Рис. 13.10. Вариант применения взаимодействия FindCourse306Глава 13. Дополнительные аспекты реализации прецедентов13.3.
ПродолженияПродолжения (continuations) позволяют фрагменту взаимодействияпоказать, что его поток завершается таким образом, что он может бытьподхвачен и продолжен другим фрагментом взаимодействия. Продол жение изображается в виде метки внутри прямоугольника со скруг ленными углами.Продолжения обеспечивают возможность завершать фрагмент взаимодействия таким образом, что его может продолжить другой фрагмент.Когда продолжение является последним элементом фрагмента взаи модействия, оно обозначает точку, в которой этот фрагмент заверша ется, но может быть продолжен другими фрагментами.Если продолжение является первым элементом фрагмента взаимодей ствия, оно показывает, что этот фрагмент является продолжениемпредыдущего фрагмента.Продолжения обеспечивают способ соединения разных взаимодейст вий.
По сути, одно взаимодействие завершается, оставляя свои линиижизни в определенном состоянии, а другие взаимодействия могут при соединиться в этой точке и продолжить работу.Визуальный синтаксис продолжений аналогичен инвариантам состоя ния, которые обсуждались в разделе 12.9.4. Однако продолжение – этолишь способ соединения разных взаимодействий в помеченных точ ках. Оно не обязательно отображается в конкретное состояние автома та контекстного классификатора.На рис.
13.11 показана простая диаграмма последовательностей, на ко торой :RegistationUI (UI – пользовательский интерфейс) вызывает актера:Registrar сначала для получения имени курса, а затем для осуществле ния одной из трех операций: добавить, удалить или найти. В зависимо сти от того, какой вариант выбран, взаимодействие заканчивается од ним из трех продолжений: addCourse, removeCourse или findCourse.На рис. 13.12 можно увидеть взаимодействие HandleCourseOption (произ вести действие над курсом), которое включает GetCourseOption (получитьвариант действия над курсом) и затем выбирает одно из его продолже ний.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
