UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
реализации прецедентов 13.1. План главы В этой главе представлены некоторые дополнительные возможности диаграмм взаимодействия, помогающие справляться с запутанностью диаграмм, обусловленной природой разрабатываемых систем. Услож нение диаграмм возникает и на стадии анализа, и при проектирова нии. Всегда нужно стремиться создавать максимально простые диа граммы взаимодействия, однако иногда это невозможно. В этих случа ях надо попробовать методы, представленные в этой главе. 13.4. Что мы узнали 13.2. Включения взаимодействий 13.3. Продолжения 13.2.1. Параметры 13.2.2. Шлюзы Рис. 13.1. План главы 300 Глава 13. Дополнительные аспекты реализации прецедентов 13.2. Включения взаимодействий Очень часто одна и та же последовательность сообщений многократно встречается в разных диаграммах последовательностей. Очевидно, что перерисовывать много раз один и тот же фрагмент взаимодействия – занятие утомительное и чреватое появлением ошибок. Поэтому в этих случаях применяются включения взаимодействий. Включения взаимодействий – это ссылки на другое взаимодействие. Включения взаимодействий – это ссылки на взаимодействие. Когда такое включение помещается во взаимодействие, то в данной точке включается поток взаимодействия, на который ссылается данное вклю чение взаимодействия. Давайте в качестве примера рассмотрим фрагмент простой системы регистрации курсов, которая обсуждалась в главе 12. Диаграмма классов анализа для интересующей нас части системы представлена на рис. 12.7 (стр. 276). Прежде чем актер Registrar (рис. 12.6) сможет работать с системой, он должен в нее войти. Это требование реализуется путем добавления на диаграмму (рис. 12.7) класса SecurityManager (менеджер безопасности), как показано на рис. 13.2. Рассмотрим прецедент LogOnRegistrar (вход регистратора в систему), по казанный на рис. 13.3. Он будет включен во все прецеденты, в кото рых Registrar сначала должен войти в систему. Можно полагать, что фрагмент взаимодействия для входа Registrar в систему будет иметь место в начале многих диаграмм последователь ностей. Имеет смысл выделить это общее поведение в отдельную диа грамму последовательностей и затем ссылаться на нее в случае необхо RegistrationManager Course 1 0..* courses Student 1 0..* students registration 0..* 0..* SecurityManager 1 1 Рис. 13.2. На диаграмму классов анализа добавлен класс SecurityManager 13.2. Включения взаимодействий 301 димости. На рис. 13.4 показана диаграмма последовательностей LogOn Registrar, содержащая многократно используемый фрагмент взаимо действия. На рис. 13.5 представлена другая диаграмма последовательностей, Chan geStudentAddress (изменить адрес студента), включающая взаимодейст вие LogOnRegistrar. Вся последовательность событий ChangeStudentAddress представлена в табл. 13.1. ID: 4 Главные актеры: Registrar Предусловия: 1. Registrar еще не вошел в систему. Основной поток: 1. Прецедент начинается, когда Registrar выбирает «log on». 2. Система спрашивает у Registrar имя пользователя и пароль. 3. Registrar вводит имя пользователя и пароль. 4. Система принимает имя пользователя и пароль как действительные. Постусловия: 1. Registrar вошел в систему. Прецедент: LogOnRegistrar Краткое описание: Registrar входит в систему. Альтернативные потоки: InvalidUserNameAndPassword RegistrarAlreadyLoggedOn Второстепенные актеры: Нет. Рис. 13.3. Спецификация прецедента LogOnRegistrar :SecurityManager logOn( userName, password ) sd LogOnRegistrar :Registrar authenticate( userName, password ) Рис. 13.4. Диаграмма последовательностей, содержащая многократно используемый фрагмент взаимодействия 302 Глава 13. Дополнительные аспекты реализации прецедентов Таблица 13.1 Приведем несколько моментов, о которых необходимо помнить при использовании включений взаимодействия. • Взаимодействие, на которое ссылается включение, вставляется во включающее взаимодействие в точке, где впервые появляется вклю чение взаимодействия. • По завершении включаемого взаимодействия необходимо быть очень внимательным к тому, где оказывается фокус управления! Следующее сообщение, отправляемое во включающем взаимодей ствии, должно быть согласовано с положением фокуса. • Все линии жизни, участвующие во включении, должны присутст вовать и во включающем взаимодействии. • Чтобы обозначить область действия включения взаимодействия, оно отрисовывается поверх всех используемых им линий жизни. 13.2.1. Параметры Взаимодействия могут иметь параметры. Это обеспечивает возмож ность поставлять взаимодействию разные значения в каждом включе нии взаимодействия. Параметры могут быть заданы с помощью обыч ного синтаксиса операций, рассмотренного в разделе 7.5.3. Диаграмма Исходная линия жизни Сообщение Целевая линия жизни LogOnRegistrar :Registrar logOn(...) :SecurityManager LogOnRegistrar :SecurityManager authenticate(...) :SecurityManager ChangeStudentAddress :Registrar findStudent(...) :RegistrationManager ChangeStudentAddress :Registrar setAddress theStudent:Student :SecurityManager sd ChangeStudentAddress :Registrar :RegistrationManager theStudent:Student включение взаимодействия ref LogOnRegistrar theStudent = findStudent( name ) setAddress( newAddress ) Рис. 13.5. Диаграмма последовательностей с включением взаимодействия 13.2. Включения взаимодействий 303 Параметры дают возможность использовать конкретные значения во взаимодействии. На рис. 13.6 показаны операции FindStudent(...) и FindCourse(...) – два па раметризованных взаимодействия. На рис. 13.7 показан пример использования параметризованных взаи модействий. Обратите внимание на то, как можно передавать во взаи :RegistrationManager findCourse( name ) sd FindCourse( name : String ) : Course :Registrar :RegistrationManager findStudent( name ) sd FindStudent( name : String ) : Student :Registrar Рис. 13.6. Параметризованные взаимодействия :RegistrationManager register( theStudent ) sd RegisterJimForUMLCourse :Registrar theCourse:Course ref theStudent = FindStudent( "Jim" ) ref theCourse = FindCourse( "UML" ) Рис. 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. шлюзы :RegistrationManager findCourse( name ) sd FindCourse :RegistrationManager findStudent( name ) sd FindStudent Рис. 13.8. Шлюзы 13.2. Включения взаимодействий 305 И шлюзы, и параметры обеспечивают гибкость в многократном ис пользовании взаимодействий. Возникает вопрос: когда должны при меняться шлюзы, а когда – параметры? • Параметры используются, когда известны исходные и целевые ли нии жизни всех сообщений взаимодействия. • Шлюзы используются, когда некоторые сообщения приходят из за границ рамки взаимодействия и заранее неизвестно, откуда они мо гут поступить. :RegistrationManager register( theStudent ) sd RegisterJimForUMLCourse :Registrar theCourse:Course theStudent = findStudent( "Jim" ) theCourse = findCourse( "UML" ) шлюз ref FindStudent ref FindCourse Рис. 13.9. Диаграммы последовательностей с шлюзами :RegistrationManager theStudents = getStudents() sd GetStudentsOnUMLCourse :Registrar uml:Course getRegisteredStudents( "UML" ) uml = findCourse( "UML" ) ref FindCourse Рис. 13.10. Вариант применения взаимодействия FindCourse 306 Глава 13. Дополнительные аспекты реализации прецедентов 13.3. Продолжения Продолжения (continuations) позволяют фрагменту взаимодействия показать, что его поток завершается таким образом, что он может быть подхвачен и продолжен другим фрагментом взаимодействия. Продол жение изображается в виде метки внутри прямоугольника со скруг ленными углами. Продолжения обеспечивают возможность завершать фрагмент взаимо действия таким образом, что его может продолжить другой фрагмент. Когда продолжение является последним элементом фрагмента взаи модействия, оно обозначает точку, в которой этот фрагмент заверша ется, но может быть продолжен другими фрагментами. Если продолжение является первым элементом фрагмента взаимодей ствия, оно показывает, что этот фрагмент является продолжением предыдущего фрагмента. Продолжения обеспечивают способ соединения разных взаимодейст вий. По сути, одно взаимодействие завершается, оставляя свои линии жизни в определенном состоянии, а другие взаимодействия могут при соединиться в этой точке и продолжить работу. Визуальный синтаксис продолжений аналогичен инвариантам состоя ния, которые обсуждались в разделе 12.9.4. Однако продолжение – это лишь способ соединения разных взаимодействий в помеченных точ ках. Оно не обязательно отображается в конкретное состояние автома та контекстного классификатора. На рис. 13.11 показана простая диаграмма последовательностей, на ко торой :RegistationUI (UI – пользовательский интерфейс) вызывает актера :Registrar сначала для получения имени курса, а затем для осуществле ния одной из трех операций: добавить, удалить или найти. В зависимо сти от того, какой вариант выбран, взаимодействие заканчивается од ним из трех продолжений: addCourse, removeCourse или findCourse. На рис. 13.12 можно увидеть взаимодействие HandleCourseOption (произ вести действие над курсом), которое включает GetCourseOption (получить вариант действия над курсом) и затем выбирает одно из его продолже ний. Как видите, продолжения позволяют: • разъединить взаимодействия GetCourseOption и HandleCourseOption; • потенциально повторно использовать GetCourseOption и HandleCourse Option с другими взаимодействиями, имеющими аналогичные про должения. При использовании продолжений необходимо помнить следующее: • Продолжения начинают и заканчивают взаимодействия, следова тельно, они должны быть или первым, или последним элементом взаимодействия. 13.3. Продолжения 307 • В контексте данного классификатора продолжения под одним име нем должны охватывать один набор линий жизни. • Продолжения имеют смысл, только если во взаимодействии при сутствует хотя бы слабое упорядочение – очевидно, что если нет упорядочения, неизвестно, где будет находиться продолжение. • Продолжения должны охватывать все линии жизни включающего их фрагмента (т. е. они являются глобальными в рамках этого фраг мента). :Registrar :RegistrationUI option = получить опцию alt sd GetCourseOption [option == add] [option == remove] [option == find] продолжение addCourse removeCourse findCourse name = получить имя курса Рис. 13.11. Диаграмма последовательностей с тремя продолжениями sd HandleCourseOption :Registrar :RegistrationUI :RegistrationManager alt продолжение ref GetCourseOption addCourse removeCourse findCourse addCourse( name ) removeCourse( name ) findCourse( name ) Рис. 13.12. Взаимодействие HandleCourseOption включает GetCourseOption и затем выбирает одно из его продолжений 308 Глава 13. Дополнительные аспекты реализации прецедентов Продолжения часто используются с оператором alt, как показано на рис. 13.12, для создания точек ветвления во взаимодействии. 13.4. Что мы узнали В этой главе были рассмотрены дополнительные возможности диа грамм взаимодействия. Мы изучили следующее: • Включения взаимодействий – это ссылки на другое взаимодействие. • Поток используемого взаимодействия включается в поток ис пользующего его взаимодействия. • Параметры – включения взаимодействия могут иметь парамет ры; используется обычная нотация параметров. • Шлюзы – входы и выходы взаимодействий: • точка на рамке диаграммы последовательностей, соединяю щая сообщение, находящееся вне рамки, с сообщением, нахо дящимся внутри рамки; сигнатуры обоих сообщений должны быть одинаковыми. • Параметры используются, когда известны источники и цели всех сообщений; в противном случае используются шлюзы. • Продолжения – завершают фрагмент взаимодействия таким обра зом, чтобы его мог продолжить другой фрагмент: • если продолжение – первый элемент фрагмента, то фрагмент продолжает другой фрагмент; • если продолжение – последний элемент фрагмента, то фрагмент завершается, но может быть продолжен другим фрагментом. 14 Диаграммы деятельности 14.1. План главы Диаграммы деятельности – это «ОО блок схемы». Они позволяют мо делировать процесс как деятельность, состоящую из коллекции соеди ненных ребрами узлов. UML 2 вводит новую семантику диаграмм дея тельности, которая обеспечивает им намного большую мощь и гиб кость, чем ранее. В этой главе рассматриваются основы диаграмм дея тельности в объеме, достаточном для моделирования деятельности. Более глубокие вопросы рассматриваются в следующей главе. 14.2. Что такое диаграммы деятельности Диаграммы деятельности часто называют «ОО блок схемами». Они позволяют моделировать процесс как деятельность, которая состоит из коллекции соединенных ребрами узлов. В UML 1 диаграммы деятельности фактически были лишь особым слу чаем диаграмм состояний (глава 21), где у каждого состояния было входное действие, которое определяло некоторый процесс или функ цию, имеющие место при входе в состояние. В UML 2 диаграммы дея тельности имеют совершенно новую семантику, базирующуюся на технологии сетей Петри (Petri Nets). В использовании этой техноло гии есть два преимущества: 1. Формализм сети Петри обеспечивает большую гибкость при моде лировании различных типов потока. 2. В UML теперь есть четкое разделение между диаграммами деятель ности и диаграммами состояний. Диаграммы деятельности – это ОО блок схемы. 310 Глава 14. Диаграммы деятельности 14.10. Контакты 14.2. Что такое диаграммы деятельности 14.4. Деятельности 14.3. Диаграммы деятельности и UP 14.5. Семантика деятельности 14.6. Разделы деятельности изучаем контакты изучаем узлы действия изучаем узлы управления изучаем объектные узлы 14.7. Узлы действия 14.7.1. Узел вызова действия 14.7.2. Узел действия, принимающий событие времени 14.8. Узлы управления 14.8.1. Начальный и конечные узлы 14.8.2. Узлы решения и слияния 14.8.3. Узлы ветвления и объединения – параллелизм 14.11. Что мы узнали 14.9. Объектные узлы 14.9.1. Семантика буфера объектного узла 14.9.2. Представление объектов в состоянии 14.9.3. Параметры деятельности Р и с. 14. 1 . Пл ан гл ав ы 14.3. Диаграммы деятельности и UP 311 Деятельность может быть добавлена к любому элементу модели с целью моделирования его поведения. Элемент обеспечивает контекст для дея тельности, и деятельность может использовать возможности своего кон текста. Деятельности обычно добавляются к: • прецедентам; • классам; • интерфейсам; • компонентам; • кооперациям; • операциям. Диаграммы деятельности также могут использоваться для моделиро вания бизнес процессов и рабочих потоков. Мы кратко покажем, как это делать, но более сложные аспекты выходят за рамки этой книги. Хотя диаграммы деятельности обычно используются как блок схемы операций, следует отметить, что исходный код операции в виде кода или псевдокода, возможно, является лучшим и более кратким их пред ставлением! Так что о каждом случае необходимо судить отдельно. Хорошая диаграмма деятельности сосредоточена на отражении лишь одного определенного аспекта динамического поведения системы. Та ким образом, она должна находиться на соответствующем уровне абст ракции, чтобы донести эту идею до целевой аудитории, и содержать минимум необходимой информации. Диаграммы деятельности можно дополнять состояниями и потоками объектов, но необходимо постоян но спрашивать себя, проясняют ли эти элементы диаграмму или дела ют ее еще более запутанной? Как обычно, лучше придерживаться мак симальной простоты. |