Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

Подождите немного. Документ загружается.

294 Глава 12. Реализация прецедентов

• найти запись студента – нельзя зарегистрировать студента на курс,

если его нет в системе;

• найти необходимый курс;

• зарегистрировать студента на курс.

На рис. 12.24 широко представлены условия, чтобы продемонстриро

вать варианты их применения в коммуникационных диаграммах. Ус

ловия не имеют формального синтаксиса, но обычно являются выра

жениями, в которых используются временные переменные области

действия текущего фокуса управления или атрибуты классов, участ

вующих во взаимодействии. На рис. 12.24 результаты операций find

Student(…) и findCourse(…) записываются в две временные переменные:

student (студент) и course (курс). Затем значения этих переменных ис

пользуются для вычисления значения временной булевой переменной

found (найден). found применяется для образования ветви в шаге 1.3.

Кроме того, found используется для принятия решения о формирова

нии ошибки для :Registrar на шаге 1.4.

Рассмотрим пошаговую интерпретацию рис. 12.24.

1. registerStudent( "Jim", "UML" ) – актер :Registrar посылает сообщение reg

isterStudent( "Jim", "UML" ) объекту :RegistrationManager.

1.1. findStudent( "Jim" ) – :RegistrationManager сам себе посылает сооб

щение findStudent( “Jim” ). Возвращаемое в результате этой опе

рации значение сохраняется в переменной student. В случае не

удачного поиска значение равно null.

1.2. findCourse( "UML" ) – :RegistrationManager сам себе посылает сообще

ние findCourse( "UML" ). Возвращаемое в результате этой опера

ции значение сохраняется в переменной course. В случае не

удачного поиска значение равно null.

1.3. [found] register( student ) – :RegistrationManager посылает сообще

ние register( student ) объекту course. Это сообщение защищено

условием и будет послано, если и student, и course неnull. Иначе

:RegistrationManager

1: register ( "Jim", "UML" )

:Registrar

course:Course

1.3 [found] : register( student )

1.1: student = findStudent( "Jim" )

1.4 [!found] : error()

1.2: course = findCourse( "UML" )

sd RegisterStudentForCourse

сторожевое условие

found = (student != null) & (course != null)

Рис. 12.24. Коммуникационная диаграмма с ветвлением

12.12. Что мы узнали 295

говоря, попытка зарегистрировать student на course делается

только в случае успешного обнаружения обоих объектов, stu

dent и course.

1.4. [!found] : error() – если found имеет значение false, вызывается

операция error() объекта :Registrar.

На коммуникационных диаграммах довольно сложно отчетливо пока

зать ветвления – создается впечатление, что условия разбросаны по

всей диаграмме; диаграмма очень быстро становится достаточно слож

ной. Основная рекомендация: показывайте на этих диаграммах толь

ко очень простое ветвление. Для представления сложных ветвлений

больше подходят диаграммы последовательностей.

12.12. Что мы узнали

Реализация прецедентов – важнейшая часть процесса анализа. Она

позволяет сравнить теорию с практикой, явно демонстрируя, как мо

гут взаимодействовать объекты классов для обеспечения заданного по

ведения системы. Диаграммы взаимодействий показывают, как клас

сы и объекты реализуют требования, определенные в прецеденте.

Мы изучили следующее:

• Реализации прецедентов создаются в деятельности UP Анализ преце

дента; эта деятельность формирует часть динамического представ

ления системы.

• Реализации прецедентов показывают, как взаимодействуют экзем

пляры классов анализа для реализации функциональных требова

ний, определенных прецедентом.

• Каждая реализация прецедента реализует только один преце

дент.

• Реализации прецедентов состоят из:

• диаграмм классов анализа – они должны «рассказывать исто

рию» об одном (или более) прецеденте;

• диаграммы взаимодействий – должны демонстрировать, как

взаимодействуют объекты для реализации поведения преце

дента;

• особых требований – во время реализации прецедента всегда

выясняются новые требования и их необходимо фиксировать;

• уточнений прецедента – вероятно, понадобится изменять пре

цедент во время его реализации.

• Взаимодействия – это единицы поведения контекстного классифи

катора.

• Взаимодействия могут использовать любые возможности кон

текстного классификатора.

296 Глава 12. Реализация прецедентов

• В реализации прецедента контекстный классификатор – это пре

цедент.

• Общая форма диаграммы взаимодействий показывает взаимо

действия между ролями, которые могут исполнять в этом взаи

модействии экземпляры классификатора.

• Форма экземпляров диаграммы взаимодействий показывает

взаимодействия между конкретными экземплярами классифи

катора:

• для линий жизни используется обычная нотация экземпляра.

• Линия жизни представляет участника взаимодействия – то, как эк

земпляр классификатора участвует во взаимодействии.

• Каждая линия жизни имеет необязательное имя, тип и необяза

тельный селектор.

• Все линии жизни обозначаются той же пиктограммой, что и их

тип.

• Экземпляры обозначаются путем подчеркивания имени, типа

и селектора.

• Сообщение представляет конкретный тип соединения между двумя

взаимодействующими линиями жизни.

• Синхронное сообщение (сплошная стрелка).

• Асинхронное сообщение (открытая стрелка).

• Возврат (открытая стрелка, пунктирная линия).

• Сообщение создания (открытая стрелка, сплошная линия, сте

реотип «create»).

• Сообщение уничтожения (открытая стрелка, сплошная линия,

стереотип «destroy»).

• Найденное сообщение (открытая стрелка, исходящая из заштри

хованного кружка).

• Потерянное сообщение (открытая стрелка, заканчивающаяся

в заштрихованном кружке).

• Диаграммы взаимодействий.

• Диаграммы последовательностей – акцентируют внимание на вре

менной упорядоченности сообщений.

• Коммуникационные диаграммы – акцентируют внимание на

структурных отношениях между объектами.

• Диаграммы обзора взаимодействий – акцентируют внимание

на отношениях между взаимодействиями.

• Временные диаграммы – акцентируют внимание на реальном

времени взаимодействий.

• Диаграммы последовательностей.

• Ход времени происходит сверху вниз.

12.12. Что мы узнали 297

• Линии жизни выполняются слева направо:

• у линий жизни есть вертикальные пунктирные «хвосты», от

ражающие продолжительность существования линии жизни;

• линии жизни могут иметь активации для обозначения того,

что фокус управления находится на этой линии жизни;

• линии жизни должны быть хорошо организованы, чтобы све

сти к минимуму количество пересекающихся линий.

• Поясняющие сценарии необходимо размещать на диаграмме по

следовательностей внизу слева.

• Инварианты состояний – символы состояний размещаются в со

ответствующих точках линии жизни.

• Ограничения заключаются в {} и размещаются на или рядом

с линиями жизни.

• Комбинированные фрагменты – области разного поведения на диа

граммах последовательностей.

• Оператор определяет, как исполняются его операнды.

• Сторожевое условие определяет, будут ли исполняться операнды.

• Операнд заключает в себе поведение.

• Операторы.

• opt – существует единственный операнд, который исполняется

в случае истинности условия (как if … then).

• alt – выполняется тот операнд, условие которого истинно.

• loop – loop min, max [условие]:

• loop или loop * – повторяется бесконечно;

• loop n, m – повторяется (m  n) раз;

• loop [ booleanExpression ] – повторяется, пока booleanExpression ис

тинно;

• loop 1, * [ booleanExpression ] – выполняется один раз, затем по

вторяется, пока booleanExpression истинно;

• loop [ for each object in collectionOfObjects ] – тело цикла выполня

ется один раз для каждого объекта коллекции;

• loop [ for each object in className ] – тело цикла выполняется

один раз для каждого объекта класса.

• break – если сторожевое условие истинно, выполняется операнд,

а не остальная часть взаимодействия, в которую включен опера

тор.

• ref – комбинированный фрагмент ссылается на другое взаимо

действие.

• par – все операнды исполняются параллельно.

• critical – операнд исполняется атомарно без прерывания.

298 Глава 12. Реализация прецедентов

• seq – операнды исполняются параллельно при условии выполне

ния следующего ограничения: последовательность поступления

событий на одну линию жизни от разных операндов совпадает

с последовательностью операндов.

• strict – операнды исполняются в строгой последовательности.

• neg – операнд показывает неверные взаимодействия.

• ignore – перечисляет сообщения, намеренно исключенные из взаи

модействия.

• consider – перечисляет сообщения, намеренно включенные во взаи

модействие.

• assert – данный операнд является единственным действительным

поведением в данный момент взаимодействия.

• Коммуникационные диаграммы – акцентируют внимание на струк

турных аспектах взаимодействия:

• линии жизни соединены связями;

• сообщения имеют порядковый номер – иерархическая нумера

ция соответствует вложенности фокуса управления.

• Итерация – в сообщении используются спецификатор итерации (*)

и необязательный блок итерации.

• Блок итерации определяет число повторений.

• В блоке итерации может использоваться естественный язык,

псевдокод, исходный код или нотация цикла (оператора loop)

диаграммы последовательностей.

• Итерацию по коллекции объектов можно обозначить, указав на

целевом конце связи имя роли и кратность (>1) и предварив со

общение спецификатором итерации (*). Сообщение посылается

всем объектам по очереди.

• Спецификатор параллельной итерации *// применяется для обо

значения параллельного выполнения сообщений.

• Ветвление – сообщение предваряется сторожевыми условиями. Со

общение исполняется, если сторожевое условие истинно.

• Могут возникнуть сложности с четким представлением ветвле

ния на коммуникационных диаграммах – для сложного ветвле

ния используются диаграммы последовательностей.

Дополнительные аспекты

реализации прецедентов

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..*

SecurityManager

Рис. 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

sd RegisterJimForUMLCourse

:Registrar

theCourse:Course

ref

theStudent = FindStudent( "Jim" )

ref

theCourse = FindCourse( "UML" )

Рис. 13.7. Передача конкретных значений в виде параметров